CVE-2026-81003
What it is
In the Linux kernel, the following vulnerability has been resolved: net/iucv: filter frames in afiucv_hs_rcv() by ingress device afiucv_hs_rcv() selects a socket from iucv_sk_list by matching four 8-byte name fields in the transport header alone. No check is made against the net_device the frame arrived on. This can cause a frame arriving on any netdev to be delivered to an AF_IUCV socket. Three problems follow. First, a frame arriving over HiperSockets can be delivered to a socket bound to the classic z/VM IUCV transport, which has iucv->hs_dev == NULL. iucv_sock_bind() takes the classic path whenever the requested userid matches iucv_userid, even on a guest that also has a HiperSockets device carrying the same identifier. The child socket created by afiucv_hs_callback_syn() for such a match inherits hs_dev = NULL and transport = AF_IUCV_TRANS_HIPER, so the first send() on it returns -ENODEV. The socket delivered to accept() is unusable. Second, a frame arriving on one netdev can be delivered to a socket bound to a different IQD device. Which can lead to - Accept-queue exhaustion (DoS) - Attacker-controlled peer identity in the child socket - Data injection into existing sockets - Fabric noise on the IQD fabric, where bogus replies are sent - killing established connections Third, all AF_IUCV sockets live in init_net, as iucv_sock_alloc() calls sk_alloc(&init_net, ...). But even frames arriving on netdev devices in a namespace can be delivered to an IUCV socket. So a process in an unprivileged user and network namespace holding only the CAP_NET_RAW capability valid within that namespace can send a raw ETH_P_AF_IUCV frame on its own lo device and have it matched against init_net sockets. Fix all three by skipping any socket whose hs_dev does not match the ingress device. A classic z/VM IUCV socket has hs_dev == NULL; the ingress dev is never NULL, so classic sockets are skipped automatically. An unbound HIPER socket also has hs_dev == NULL and is skipped. A bound HIPER socket is only reachable from the exact IQD device it was bound to. Because hs_dev is always a device in init_net (iucv_sock_bind() scans for_each_netdev_rcu(&init_net, ...) exclusively), a frame whose ingress device belongs to another namespace never matches any socket. Note that AF_IUCV over HiperSockets provides no per-connection authentication: no sequence numbers, no TLS, no nonce. The four name fields identifying a connection are exchanged in plaintext on the shared HiperSockets segment (VCHID). Any host on the same HiperSockets segment could spoof any frame type against an existing connection. That is a protocol-level property unchanged by this patch. The fix reduces the attack surface to peers present on the same HiperSockets segment.
At a glance
- Exploitability
- Can be exploited from the same network segment without logging in. High risk of data tampering, service disruption.
- Exploit odds
- 0.3% chance of exploitation in the next 30 days (EPSS).
- Fix
- No patch or advisory is linked yet. Look at mitigations or restrict exposure.
Timeline
- ReservedThe CVE id was reserved by its CNA
- PublishedDisclosed publicly on CVE.org and NVD
- Last updatedMost recent change to the record
Why it ranks here
- Exploited in the wild: no, CISA does not list it.
- Exploit odds: 0.3% in the next 30 days (EPSS).
- Severity: 8.1 HIGH (CVSS).
- Fix: none linked yet, which raises it.
Details
- Published
- Last modified
- Exploit probability
- 0.3% · EPSS, next 30 days
- Record status
- Received
Attack profile CVSS 3.1 · 8.1
- Attack vector
- Adjacent network
- Complexity
- Low
- Privileges needed
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- None
- Integrity
- High
- Availability
- High
Raw vector
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H
Is it in your code?
Hand this to your coding agent. It searches your project for the affected products and checks versions. Nothing leaves your machine.
Read https://cve-list.com/agent/cve/CVE-2026-81003.md and follow it. Check whether this project is affected by CVE-2026-81003. Read only. Don't change anything and don't upload my code. Tell me yes, no or not sure, with the file as proof.
References
- https://git.kernel.org/stable/c/0a5af67e7184c6a0e155c317840bd64b37177af4
- https://git.kernel.org/stable/c/639828ad4d374056167391dbaffd13dd5e5e5ddb
- https://git.kernel.org/stable/c/712330f8a4293cfd97b0d62b7c7dc01862a16b98
- https://git.kernel.org/stable/c/80230a18c164a4b5bbc048fe2768b219ac17bc5a
- https://git.kernel.org/stable/c/8e3763f1ccac3fc395f9af2b87114c023ced8a3f
- https://git.kernel.org/stable/c/92e5c281f1caa287bb58292f2687c9e3ff3aa23e
- https://git.kernel.org/stable/c/a7f0130a091724e69827ab58e74777a88747e892
- https://git.kernel.org/stable/c/dfac2936b83be00035ae176f8252e1c1e1de9207