CVE-2026-74665: Linux Kernel Information Disclosure Vulnerability

CVE-2026-74665 Overview

CVE-2026-74665 is a Linux kernel vulnerability in the generic eXpress Data Path (XDP) receive code that leaves the socket buffer (skb) length accounting inconsistent after an XDP program adjusts fragment data. When an XDP program shrinks a non-linear fragment area, bpf_prog_run_generic_xdp() writes the new size into skb->data_len but does not update skb->len, causing skb_headlen() to report a linear area larger than reality. Downstream code such as __skb_datagram_iter() then reads past the linear tail into struct skb_shared_info, copying kernel memory including nr_frags, xdp_frags_size, and a kernel pointer from skb_shinfo(skb)->frags[0] into userspace.

Critical Impact
A remote attacker can trigger out-of-bounds reads that leak kernel memory including pointer values usable to defeat KASLR, and corrupt UDP receive payloads on interfaces running generic XDP programs that adjust fragment areas.

Affected Products

Linux kernel branches containing the generic XDP fragment-adjustment path prior to the referenced stable fixes
Network paths using generic XDP (bpf_prog_run_generic_xdp()) on devices exposing non-linear skb fragments, including veth pairs with large MTUs
Systems processing UDP datagrams over interfaces where an XDP program shrinks the fragment area

Discovery Timeline

2026-08-22 - CVE-2026-74665 published to the National Vulnerability Database
2026-08-25 - Last updated in NVD database

Technical Details for CVE-2026-74665

Vulnerability Analysis

Generic XDP exposes non-linear skb fragments to eBPF programs through an xdp_buff structure. When an XDP program modifies the fragment region, the kernel must synchronize both skb->len and skb->data_len, which together define where the linear header area ends and the paged fragment area begins.

The defective code copies the new xdp_frags_size into skb->data_len but leaves skb->len reflecting the pre-adjustment fragment contribution. Because skb_headlen() returns skb->len - skb->data_len, a shrink operation inflates the reported linear header length by exactly the number of bytes removed from the fragments.

Any receive path that trusts skb_headlen() then walks past the actual linear tail. In the reproduced UDP case, __skb_datagram_iter() copied 1024 bytes of memory beginning at struct skb_shared_info into userspace. The disclosed region contains nr_frags, xdp_frags_size, and raw kernel pointers stored in skb_shinfo(skb)->frags[0]. The same 1024 bytes displaced real packet payload, truncating the datagram at the tail.

Root Cause

The root cause is missing length bookkeeping in bpf_prog_run_generic_xdp(). The function replaces skb->data_len without first subtracting the old value from skb->len and adding the new value back, breaking the invariant that skb->len == skb_headlen(skb) + skb->data_len. This classifies as an Out-of-Bounds Read leading to Information Disclosure.

Attack Vector

An attacker sends crafted network traffic to a host where a generic XDP program adjusts fragment sizes on ingress. A 60000-byte UDP datagram traversing a veth pair with MTU 64000 reliably triggers the corruption. In all ten test runs before the patch, the receiver read 1024 bytes of kernel shared-info memory in place of packet data. The disclosed kernel pointer can be used to bypass Kernel Address Space Layout Randomization (KASLR) and stage further exploitation. No local privileges or user interaction are required on the receiving host.

No public exploit code is available. See the upstream fix in Kernel Patch Commit 33f2b2e for the exact patch semantics.

Detection Methods for CVE-2026-74665

Indicators of Compromise

Truncated UDP payloads on interfaces where a generic XDP program is attached and shrinks fragment areas
Userspace receive buffers containing byte sequences resembling struct skb_shared_info fields such as small integer nr_frags values followed by 8-byte aligned kernel pointers in the 0xffff... range
Repeated packet-length mismatches between recvmsg() return values and expected datagram sizes on veth or tunnel interfaces with large MTUs

Detection Strategies

Audit hosts for attached generic XDP programs using ip link show and bpftool net show, and identify programs that call helpers adjusting xdp_frags_size
Instrument the receive path with kernel tracing (kprobe on bpf_prog_run_generic_xdp) to log discrepancies between skb->len and skb_headlen(skb) + skb->data_len
Monitor dmesg and audit logs for anomalies in network stack behavior following XDP program loads

Monitoring Recommendations

Ingest kernel and eBPF program load events into a centralized analytics platform to correlate XDP program deployments with anomalous datagram truncation reports
Track kernel package versions across the fleet and alert on hosts running builds prior to the fixed commits 33f2b2eb, 5f30f9c3, 72468efc, and ea1ccd6d
Watch for unusual UDP receive-error rates on interfaces carrying jumbo frames or fragmented traffic

How to Mitigate CVE-2026-74665

Immediate Actions Required

Apply the upstream stable kernel patches referenced by commits 33f2b2eb, 5f30f9c3, 72468efc, and ea1ccd6d to all affected kernel branches
Inventory production hosts using generic XDP and prioritize patching those running BPF programs that call fragment-adjustment helpers
Restart affected workloads after patching to ensure new kernel code paths are in use

Patch Information

The fix subtracts the old data_len from skb->len before assigning the new xdp_frags_size, then adds the new data_len back, restoring the skb->len and skb->data_len invariant. Verified UDP reproductions show corrupted payloads in all ten pre-patch runs and matching payloads in all ten post-patch runs. Apply the patch from Kernel Patch Commit 33f2b2e or the equivalent stable-tree backport for your kernel branch.

Workarounds

Detach generic XDP programs that adjust fragment areas until the kernel is patched, using ip link set dev <iface> xdpgeneric off
Constrain interface MTU to values that keep receive packets within the linear area, avoiding non-linear skb fragments where feasible
Prefer native or offloaded XDP modes on drivers that support them, as the defect is specific to the generic XDP receive path

bash

# Disable generic XDP on an affected interface as a temporary workaround
sudo ip link set dev veth0 xdpgeneric off

# Verify no generic XDP program remains attached
ip -details link show dev veth0 | grep -i xdp
sudo bpftool net show