CVE-2026-74612 in Linux
Summary
by MITRE • 08/22/2026
In the Linux kernel, the following vulnerability has been resolved:
veth: fix skb length accounting after XDP frag adjustment
veth exposes non-linear skb fragments through an xdp_buff. If an XDP program adjusts the fragment area, veth_xdp_rcv_skb() copies xdp_frags_size back to skb->data_len but leaves skb->len containing the old fragment contribution.
After a fragment shrink, this makes skb_headlen() larger than the actual linear area. In the reproduced UDP receive path, __skb_datagram_iter() copied 1024 bytes past the actual linear tail to userspace, starting at struct skb_shared_info. The copied bytes included the affected skb's nr_frags, xdp_frags_size, and a kernel pointer from skb_shinfo(skb)->frags[0]. Real packet data was displaced by the same
amount and truncated at the end.
Subtract the old data_len before replacing it and add the new data_len afterwards, keeping skb->len and skb->data_len synchronized.
Additionally, bpf_xdp_pull_data() can advance data_end while leaving frags present. The skb is then still non-linear, so the old __skb_put(skb, off) triggers SKB_LINEAR_ASSERT().
Use skb_set_tail_pointer() and update skb->len explicitly instead, following bpf_prog_run_generic_xdp(). Unlike __skb_put(), skb_set_tail_pointer() does not require a linear skb.
A 60000-byte UDP datagram on a veth pair with MTU 64000 was shortened by 1024 bytes from its fragment area. Before the fix, all 10 runs produced corrupted payloads. After the fix, all 10 runs matched the expected payload exactly. A forced-tailroom reproducer also exercises bpf_xdp_pull_data() with frags still present; the old code triggers SKB_LINEAR_ASSERT(), while this fix passes 10/10 runs.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/23/2026
The Linux kernel veth driver contains a critical memory accounting flaw related to how it handles XDP fragment adjustments, specifically within the veth_xdp_rcv_skb function. This vulnerability arises when an eXpress Data Path program modifies the fragment area of a socket buffer. The core technical failure lies in the incorrect synchronization between skb->len and skb->data_len fields during this adjustment process. When the fragment size is reduced, the code correctly updates data_len to reflect the new smaller fragment contribution but fails to adjust len accordingly, leaving it with the old, larger value that includes the previous fragment contribution. This desynchronization creates an inconsistent state where the kernel's internal representation of packet boundaries no longer matches the actual memory layout and content available for processing.
The operational impact of this inconsistency is severe, particularly in UDP receive paths where data integrity is paramount. Because skb->len remains artificially high while the linear portion has effectively shrunk due to fragment adjustments, subsequent functions that rely on these metrics miscalculate buffer boundaries. Specifically, __skb_datagram_iter() interprets the inflated length as valid linear data and proceeds to copy bytes from beyond the actual end of the linear area. This results in a heap out-of-bounds read where up to 1024 bytes past the true linear tail are copied into userspace memory. The data retrieved includes sensitive kernel structures such as nr_frags, xdp_frags_size, and crucially, kernel pointers embedded within skb_shinfo(skb)->frags[0]. This constitutes a significant information disclosure vulnerability that can leak kernel addresses to unprivileged processes or network peers, potentially aiding further exploitation attempts like kernel address space layout randomization bypasses.
Beyond the immediate data corruption and information leakage, this flaw also triggers stability issues under specific conditions involving bpf_xdp_pull_data(). When this BPF helper advances the data_end pointer while leaving fragments present, the socket buffer remains non-linear. The original implementation attempted to adjust the tail using __skb_put(), which includes an assertion that requires a linear skb structure. Consequently, this mismatch causes the kernel to trigger SKB_LINEAR_ASSERT(), leading to a denial of service through a kernel panic or crash. This demonstrates how improper state management in network stack components can lead not only to security breaches but also to system instability and availability loss for services relying on veth interfaces.
The remediation involves correcting the length accounting logic by subtracting the old data_len before replacing it with the new value, thereby ensuring skb->len and skb->data_len remain synchronized throughout the XDP processing pipeline. Additionally, the code path handling bpf_xdp_pull_data() was updated to use skb_set_tail_pointer() instead of __skb_put(). This function does not enforce linear buffer requirements, allowing for safe tail adjustments even when fragments are present, aligning with standard practices seen in generic XDP program execution paths. These changes ensure that packet data is neither truncated nor corrupted and prevent the exposure of kernel memory structures to user space or network peers.
From a classification perspective, this vulnerability maps directly to CWE-134: Use of Externally-Controlled Format String if considering the potential for format string attacks via leaked pointers, but more accurately aligns with CWE-787: Out-of-bounds Write and CWE-200: Exposure of Sensitive Information to an Unauthorized Actor due to the heap out-of-bounds read. In terms of attack vectors, it relates to ATT&CK technique T1564.003: Hidden Files and Directories if considering how leaked data might be used for stealthy exploitation, though primarily it represents a memory safety violation typical in low-level network driver development. The fix ensures that veth interfaces maintain strict adherence to kernel memory management protocols during high-performance XDP operations, preserving both confidentiality and integrity of transmitted UDP datagrams across virtual Ethernet pairs.