CVE-2026-74665: net: fix skb length accounting after generic XDP frag adjustment
In the Linux kernel, the following vulnerability has been resolved:
net: fix skb length accounting after generic XDP frag adjustment
Generic XDP exposes non-linear skb fragments through an xdpbuff. If an XDP program adjusts the fragment area, bpfprogrungenericxdp() copies xdpfragssize back to skb->datalen but leaves skb->len containing the old fragment contribution.
After a fragment shrink, this makes skbheadlen() larger than the actual linear area. In the reproduced UDP receive path, skbdatagramiter() copied 1024 bytes past the actual linear tail to userspace, starting at struct skbsharedinfo. The copied bytes included the affected skb's nrfrags, xdpfragssize and a kernel pointer from skbshinfo(skb)->frags[0]. Real packet data was displaced by the same amount and truncated at the end.
Subtract the old datalen before replacing it and add the new datalen afterwards, keeping skb->len and skb->datalen synchronized.
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.
Affected Software
Event History
Frequently Asked Questions
What conditions are required for exposure?
The affected path requires Generic XDP operating on non-linear skb fragments and an XDP program that adjusts the fragment area. The demonstrated case used a large UDP datagram on a veth pair with an MTU of 64000 and reduced the fragment area by 1024 bytes.
What can an application observe if the issue is triggered?
UDP payloads can be corrupted: real packet data is displaced and truncated at the end. In the reproduced receive path, 1024 bytes beyond the actual linear tail were copied to userspace, including skb metadata such as nr_frags, xdp_frags_size, and a kernel pointer from the first fragment entry.
How can I validate whether the fix is effective in my environment?
Use traffic that exercises Generic XDP fragment adjustment and compare received payloads against the expected data. In the reported 60000-byte UDP test with a 1024-byte fragment shrink, every run was corrupted before the fix and every run matched exactly after the fix.