Skip to main content
Stopping PHP2SHELL: How SentinelOne Protects Customers From This Attack TechniqueRead More
Vulnerability Database/CVE-2026-81003

CVE-2026-81003: Linux Kernel AF_IUCV DOS Vulnerability

CVE-2026-81003 is a denial of service flaw in Linux kernel AF_IUCV that allows frame filtering bypass and socket exploitation. This post explains its impact, affected versions, and mitigation steps.

Published:

CVE-2026-81003 Overview

CVE-2026-81003 is a Linux kernel vulnerability in the AF_IUCV socket implementation (net/iucv). The function afiucv_hs_rcv() selects a destination socket from iucv_sk_list by matching four 8-byte name fields carried in the transport header. The code performs no validation against the net_device the frame arrived on. Frames from any network device can therefore be delivered to an AF_IUCV socket bound to a different device, transport, or network namespace. The flaw enables denial of service, connection hijacking on the IQD fabric, data injection into existing sockets, and cross-namespace frame delivery from an unprivileged user namespace holding only CAP_NET_RAW.

Critical Impact

An adjacent-network attacker on a shared HiperSockets segment can inject data into established AF_IUCV connections, exhaust accept queues, and terminate active sessions.

Affected Products

  • Linux kernel builds compiled with CONFIG_AF_IUCV on IBM Z (s390/s390x)
  • Systems using AF_IUCV over HiperSockets (IQD devices)
  • z/VM guests exposing classic IUCV or HiperSockets transports to workloads

Discovery Timeline

  • 2026-09-11 - CVE-2026-81003 published to NVD
  • 2026-09-14 - Last updated in NVD database

Technical Details for CVE-2026-81003

Vulnerability Analysis

The afiucv_hs_rcv() handler in net/iucv/af_iucv.c demultiplexes incoming ETH_P_AF_IUCV frames to sockets in iucv_sk_list. Selection depends solely on four plaintext 8-byte identifiers in the transport header. The ingress net_device is never compared against the socket's bound device (iucv->hs_dev).

Three failure modes result. A HiperSockets frame can match a socket bound to the classic z/VM IUCV transport, producing a child socket where hs_dev == NULL and transport == AF_IUCV_TRANS_HIPER. The first send() on such a socket returns -ENODEV, leaving accept() consumers with an unusable descriptor. A frame arriving on one IQD device can also match a socket bound to a different IQD device, allowing accept-queue exhaustion, attacker-controlled peer identity in child sockets, injection into existing sockets, and termination of established connections.

All AF_IUCV sockets live in init_net because iucv_sock_alloc() calls sk_alloc(&init_net, ...). Frames arriving on devices inside another network namespace still match init_net sockets. A process in an unprivileged user and network namespace holding only namespace-local CAP_NET_RAW can transmit a crafted ETH_P_AF_IUCV frame on its own lo device and reach host sockets.

Root Cause

The receive path performs socket lookup on transport-header name fields without cross-checking the ingress net_device. Missing validation between the frame source and the socket binding permits cross-device, cross-transport, and cross-namespace delivery.

Attack Vector

Exploitation requires adjacency on a shared HiperSockets (VCHID) segment or the ability to emit raw ETH_P_AF_IUCV frames on any interface. On the shared segment, AF_IUCV provides no per-connection authentication: no sequence numbers, no TLS, no nonce. Any peer on the segment can spoof frame identifiers to hijack, disrupt, or inject data into a target connection. From a user namespace, CAP_NET_RAW on a loopback interface is sufficient to reach init_net sockets prior to the fix.

See the upstream fixes for implementation details, including Kernel Commit 0a5af67 and Kernel Commit dfac293.

Detection Methods for CVE-2026-81003

Indicators of Compromise

  • Unexpected -ENODEV errors returned from send() on newly accepted AF_IUCV sockets, indicating hs_dev/transport mismatch.
  • Sudden accept-queue saturation on AF_IUCV listeners bound to IQD devices, without a corresponding legitimate connection surge.
  • Abrupt termination of long-lived AF_IUCV connections coinciding with unfamiliar peer userids appearing in application logs.

Detection Strategies

  • Audit hosts for kernels built with CONFIG_AF_IUCV=y or CONFIG_AF_IUCV=m and identify processes with open AF_IUCV sockets via ss -x or /proc/net/iucv.
  • Correlate kernel version and s390 architecture against the fixed commits published on kernel.org to flag unpatched z/VM and HiperSockets guests.
  • Monitor for unprivileged processes creating raw sockets with ETH_P_AF_IUCV (0xFBFB) inside user namespaces, which has no legitimate use case.

Monitoring Recommendations

  • Enable auditd rules on socket() and bind() syscalls filtering for AF_IUCV (family 32) to build a baseline of legitimate use.
  • Capture and inspect HiperSockets segment traffic for duplicate or spoofed 8-byte name-field tuples targeting known active endpoints.
  • Alert on CAP_NET_RAW acquisition inside non-root user namespaces on s390x hosts running unpatched kernels.

How to Mitigate CVE-2026-81003

Immediate Actions Required

  • Apply the upstream stable kernel updates that add ingress-device filtering to afiucv_hs_rcv() on all IBM Z systems running AF_IUCV workloads.
  • Inventory z/VM guests and LPARs that use HiperSockets IQD devices and prioritize patching hosts sharing a VCHID segment with untrusted peers.
  • Restrict creation of user namespaces on s390x hosts where unprivileged workloads do not require them, reducing exposure of the CAP_NET_RAW path.

Patch Information

The fix skips any socket whose hs_dev does not match the ingress device. Classic IUCV sockets (hs_dev == NULL) and unbound HIPER sockets are skipped automatically. Because hs_dev is always resolved via for_each_netdev_rcu(&init_net, ...), frames whose ingress device belongs to another namespace no longer match any socket. Patches are available in Kernel Commit 0a5af67, Kernel Commit 639828a, Kernel Commit 712330f, Kernel Commit 80230a1, Kernel Commit 8e3763f, Kernel Commit 92e5c28, Kernel Commit a7f0130, and Kernel Commit dfac293.

Workarounds

  • Where AF_IUCV is not required, unload or blocklist the af_iucv kernel module to remove the attack surface entirely.
  • Isolate sensitive z/VM guests onto dedicated HiperSockets VCHIDs so that no untrusted peer shares the same segment.
  • Disable unprivileged user namespaces by setting kernel.unprivileged_userns_clone=0 (or the equivalent sysctl) to block the loopback-frame injection path.
bash
# Disable unprivileged user namespaces and blocklist af_iucv
sysctl -w kernel.unprivileged_userns_clone=0
echo 'kernel.unprivileged_userns_clone=0' > /etc/sysctl.d/99-cve-2026-81003.conf

echo 'blacklist af_iucv' > /etc/modprobe.d/af_iucv-blacklist.conf
echo 'install af_iucv /bin/true' >> /etc/modprobe.d/af_iucv-blacklist.conf
modprobe -r af_iucv 2>/dev/null || true

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.

Try SentinelOne