CVE-2026-74612: veth: fix skb length accounting after XDP frag adjustment

From: Greg Kroah-Hartman <[email protected]>

Description
===========

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.

The Linux kernel CVE team has assigned CVE-2026-74612 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 5.18 with commit 718a18a0c8a67f97781e40bdef7cdd055c430996 and fixed in 6.6.152 with commit 2f2a7f3f8b9f1bffc9b0488aa02b6951b2aec139
	Issue introduced in 5.18 with commit 718a18a0c8a67f97781e40bdef7cdd055c430996 and fixed in 6.12.104 with commit 41b96667d42b74bb4b137f1bb78b611a953c5943
	Issue introduced in 5.18 with commit 718a18a0c8a67f97781e40bdef7cdd055c430996 and fixed in 6.18.45 with commit cdf745b7a777f87f51666e5d8f4c6fc279bcf54d
	Issue introduced in 5.18 with commit 718a18a0c8a67f97781e40bdef7cdd055c430996 and fixed in 7.1.9 with commit 3205b0652a37255dbb7ca8f3d942c8d8aa677c21
	Issue introduced in 5.18 with commit 718a18a0c8a67f97781e40bdef7cdd055c430996 and fixed in 7.2 with commit cb6379feaaff11c4e1e79c26c745ffa23182768a

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2026-74612
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	drivers/net/veth.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/2f2a7f3f8b9f1bffc9b0488aa02b6951b2aec139
	https://git.kernel.org/stable/c/41b96667d42b74bb4b137f1bb78b611a953c5943
	https://git.kernel.org/stable/c/cdf745b7a777f87f51666e5d8f4c6fc279bcf54d
	https://git.kernel.org/stable/c/3205b0652a37255dbb7ca8f3d942c8d8aa677c21
	https://git.kernel.org/stable/c/cb6379feaaff11c4e1e79c26c745ffa23182768a