CVE-2026-74612

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> veth: fix skb length accounting after XDP frag adjustment<br /> <br /> veth exposes non-linear skb fragments through an xdp_buff. If an XDP<br /> program adjusts the fragment area, veth_xdp_rcv_skb() copies<br /> xdp_frags_size back to skb-&gt;data_len but leaves skb-&gt;len containing the<br /> old fragment contribution.<br /> <br /> After a fragment shrink, this makes skb_headlen() larger than the actual<br /> linear area. In the reproduced UDP receive path, __skb_datagram_iter()<br /> copied 1024 bytes past the actual linear tail to userspace, starting at<br /> struct skb_shared_info. The copied bytes included the affected skb&amp;#39;s<br /> nr_frags, xdp_frags_size, and a kernel pointer from<br /> skb_shinfo(skb)-&gt;frags[0]. Real packet data was displaced by the same<br /> amount and truncated at the end.<br /> <br /> Subtract the old data_len before replacing it and add the new data_len<br /> afterwards, keeping skb-&gt;len and skb-&gt;data_len synchronized.<br /> <br /> Additionally, bpf_xdp_pull_data() can advance data_end while leaving<br /> frags present. The skb is then still non-linear, so the old<br /> __skb_put(skb, off) triggers SKB_LINEAR_ASSERT().<br /> <br /> Use skb_set_tail_pointer() and update skb-&gt;len explicitly instead,<br /> following bpf_prog_run_generic_xdp(). Unlike __skb_put(),<br /> skb_set_tail_pointer() does not require a linear skb.<br /> <br /> A 60000-byte UDP datagram on a veth pair with MTU 64000 was shortened by<br /> 1024 bytes from its fragment area. Before the fix, all 10 runs produced<br /> corrupted payloads. After the fix, all 10 runs matched the expected<br /> payload exactly. A forced-tailroom reproducer also exercises<br /> bpf_xdp_pull_data() with frags still present; the old code triggers<br /> SKB_LINEAR_ASSERT(), while this fix passes 10/10 runs.