CVE-2026-74707: Linux Kernel XSK Privilege Escalation

CVE-2026-74707 Overview

CVE-2026-74707 is a time-of-check time-of-use (TOCTOU) race condition in the Linux kernel's AF_XDP (XSK) zero-copy transmit path. The zero-copy code validates TX metadata when obtaining the descriptor context, then re-reads the same metadata later while preparing the hardware request. A local user space process can modify the metadata between these two operations to bypass the initial validation and pass unvetted values to zero-copy network drivers.

Critical Impact
Local unprivileged users with access to an XSK socket can bypass metadata validation in the kernel's zero-copy TX path, potentially compromising confidentiality, integrity, and availability of the host.

Affected Products

Linux kernel versions containing the xsk_tx_metadata zero-copy TX path prior to the fix
Distributions shipping affected upstream kernels
Zero-copy capable network drivers relying on XSK TX metadata

Discovery Timeline

2026-08-22 - CVE-2026-74707 published to NVD
2026-08-25 - Last updated in NVD database

Technical Details for CVE-2026-74707

Vulnerability Analysis

The AF_XDP subsystem allows user space applications to share memory buffers (UMEM) directly with the kernel and network drivers for high-performance packet processing. In the zero-copy TX path, the kernel reads TX metadata from a user-writable buffer to determine feature flags such as checksum offload or timestamping requests.

The flaw stems from reading this metadata twice. The kernel first validates the metadata while obtaining descriptor context. It then reads the same fields again when preparing the hardware request. Because the source memory remains mapped and writable by user space, an attacker can modify the values between the check and the use.

This TOCTOU condition allows requests that would fail validation to reach zero-copy drivers with attacker-controlled feature flags and field values. Depending on the driver, this can trigger unsafe code paths, cause memory corruption in DMA descriptor handling, or influence hardware programming with invalid parameters.

Root Cause

The zero-copy path lacked a single authoritative snapshot of the TX metadata. Validation operated on one read while feature dispatch and hardware descriptor construction operated on subsequent reads of the same user-controlled memory. The fix introduces xsk_tx_metadata_request() to validate metadata once and reuse the resulting flag snapshot across all feature checks and driver code paths.

Attack Vector

Exploitation requires local access with permission to create an AF_XDP socket and bind a UMEM region on a network interface using a zero-copy capable driver. The attacker races a second thread that mutates the TX metadata region while the kernel processes descriptors. This is a local, low-privilege attack that does not require user interaction. No public proof-of-concept exploit is currently available.

The vulnerability is described in prose only; see the upstream fixes referenced below for technical implementation details:

Detection Methods for CVE-2026-74707

Indicators of Compromise

Unexpected kernel warnings or oops messages referencing xsk_tx_metadata, xsk_build_skb, or zero-copy driver TX descriptor paths
Network driver errors reporting invalid TX descriptor flags or malformed offload requests on interfaces bound to AF_XDP sockets
Processes without a legitimate operational reason opening AF_XDP sockets with the XDP_ZEROCOPY flag

Detection Strategies

Audit socket(AF_XDP, ...) system calls and correlate with the invoking user, process, and binary to identify unexpected callers
Monitor kernel ring buffer logs for driver-level warnings tied to XSK zero-copy TX processing
Use eBPF or auditd rules to record bpf() and setsockopt() operations that configure XSK UMEM and TX rings

Monitoring Recommendations

Track uname -r inventory across the Linux fleet and flag hosts running kernels that have not received the fix commits
Alert on non-root, non-service accounts creating AF_XDP sockets on production hosts
Baseline legitimate XDP applications (for example, load balancers, DPDK-adjacent tooling) and treat deviations as investigation targets

How to Mitigate CVE-2026-74707

Immediate Actions Required

Apply the upstream Linux kernel patches introducing xsk_tx_metadata_request() and reboot affected hosts
Inventory hosts that expose AF_XDP zero-copy functionality and prioritize patching multi-tenant systems first
Restrict CAP_NET_RAW and CAP_BPF capabilities to trusted service accounts and container workloads

Patch Information

The fix validates TX metadata once inside xsk_tx_metadata_request() and reuses the resulting flag snapshot for every feature check. Zero-copy drivers now consume only values observed after successful validation, eliminating the double-read window. Merge the following upstream commits or update to a stable kernel release that includes them: 0cc7aa6e0d19, 5fd121971912, and 849b1664dbda.

Workarounds

Disable zero-copy XSK mode on affected interfaces and fall back to copy mode where operationally acceptable
Use seccomp or LSM policies to block socket(AF_XDP, ...) for workloads that do not require it
Constrain container and VM workloads by dropping CAP_NET_RAW and CAP_BPF in runtime profiles

bash

# Example: block AF_XDP socket creation for a workload via seccomp allowlist
# (Reject AF_XDP by omitting it from allowed socket families in the profile)
# Verify kernel version against upstream fix
uname -r

# Check whether any process currently holds an AF_XDP socket
ss -x -a | grep -i xdp || echo "No AF_XDP sockets observed"