HIGH Introduced in 3.2
net/iucv IngressDevice Bypass
CVE-2026-81003
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H
KernelScan AI9.6CRITICAL
01Description
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.
02KernelScan AI Analysis
Risk summary
An unprivileged local process in a user and network namespace can craft raw AF_IUCV frames on its own loopback device and have them matched against sockets in the init namespace, enabling data injection, connection disruption, peer identity spoofing, and accept-queue exhaustion. The bug is specific to s390 systems with AF_IUCV HiperSockets transport support. Any host on the same HiperSockets fabric segment can also spoof frames against existing connections.
Vulnerability analysis
The AF_IUCV HiperSockets receive path delivers incoming frames to sockets based only on connection names in the packet header, without checking which network device the frame arrived on. Because all AF_IUCV sockets belong to the host's initial network namespace while frames can arrive on devices in any namespace, a process inside an unprivileged container can craft a raw frame on its own loopback device and have it delivered to a host-level socket. This enables data injection into existing connections, spoofing of peer identity in newly accepted sockets, accept-queue exhaustion, and killing of established connections. The fix adds a check that drops frames unless the socket's bound device matches the ingress device; because bound sockets always reference a host-level device, frames from other namespaces are automatically rejected. The attack requires access to an s390 system with AF_IUCV support. The primary exploit path uses unprivileged containers, which a local account can create to gain the capability needed to send raw traffic.
Lifecycle
03Fix Versions
| Branch | Introduced | Fixed in | Patch commit |
|---|---|---|---|
| 5.10 | 3.2 | 5.10.270 | 639828ad4d37 |
| 5.15 | 3.2 | 5.15.221 | 92e5c281f1ca |
| 6.1 | 3.2 | 6.1.188 | 712330f8a429 |
| 6.12 | 3.2 | 6.12.109 | dfac2936b83b |
| 6.18 | 3.2 | 6.18.50 | 8e3763f1ccac |
| 6.6 | 3.2 | 6.6.157 | 0a5af67e7184 |
| 7.2 | 3.2 | 7.2.4 | a7f0130a0917 |
| mainline | 3.2 | 7.3 | 80230a18c164 |
| cip/5.10 | 3.2 | 5.10.271-cip78 | 639828ad4d37 |
| cip/6.1 | 3.2 | 6.1.189-cip61 | 712330f8a429 |
| cip/6.1-rt | 3.2 | 6.1.189-cip61-rt32 | 712330f8a429 |
| cip/6.12 | 3.2 | 6.12.111-cip32 | dfac2936b83b |
04CIP Kernels
State of the newest release of each Civil Infrastructure Platform SLTS tree, from CIP's own fix records.
| CIP tree | State |
|---|---|
| cip/6.12 | Fixed in 6.12.111-cip32 |
| cip/6.1 | Fixed in 6.1.189-cip61 |
| cip/6.1-rt | Fixed in 6.1.189-cip61-rt32 |
| cip/5.10 | Fixed in 5.10.271-cip78 |
| cip/5.10-rt | Affected — no CIP fix yet (latest 5.10.268-cip77-rt34) |
| cip/4.19 | Affected — no CIP fix yet (latest 4.19.325-cip136) |
| cip/4.19-rt | Affected — no CIP fix yet (latest 4.19.325-cip136-rt50) |
| cip/4.4 | Affected — no CIP fix yet (latest 4.4.302-cip115) |
| cip/4.4-rt | Affected — no CIP fix yet (latest 4.4.302-cip115-rt63) |