CVE-2026-74560: xsk: fix buffer leak in xsk_drop_skb() for AF_XDP multi-buffer Tx

CVE-2026-74560: xsk: fix buffer leak in xsk_drop_skb() for AF_XDP multi-buffer Tx

[Greg Kroah-Hartman]

From: Greg Kroah-Hartman <gregkh@kernel.org>

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

In the Linux kernel, the following vulnerability has been resolved:

xsk: fix buffer leak in xsk_drop_skb() for AF_XDP multi-buffer Tx

This patch is inspired by the check[1] from sashiko. It says when
overflow happens, the address of cq to be published is invalid.
Actually the severer thing is the whole process of publishing the
address of cq in this particular case is not right: it should truely
publish the address and advance the cached_prod in cq as long as it
reads descriptors from txq.

The following is the full analysis.
xsk_drop_skb() is called in three places, which all discard a partially
built multi-buffer skb:
1) xsk_build_skb() -EOVERFLOW error path: packet exceeds MAX_SKB_FRAGS
2) __xsk_generic_xmit() post-loop cleanup: an invalid descriptor in
   the TX ring prevents the partial packet from completing
3) xsk_release(): socket close while xs->skb holds an incomplete packet

In all three cases, the TX descriptors for the already-processed frags
have been consumed from the TX ring (xskq_cons_release), and CQ slots
have been reserved. However, xsk_drop_skb() calls xsk_consume_skb()
which cancels the CQ reservations via xsk_cq_cancel_locked(). Since
the buffer addresses never appear in the completion queue, userspace
permanently loses track of these buffers.

Fix this by letting consume_skb() trigger the existing xsk_destruct_skb
destructor, which already submits buffer addresses to the CQ via
xsk_cq_submit_addr_locked().

Note that cancelling the descriptors back to the TX ring (via
xskq_cons_cancel_n) is not a appropriate option because an oversized
packet that always exceeds MAX_SKB_FRAGS would be retried indefinitely,
which is an obviously deadlock bug in the TX path.

Also move the desc->addr assignment in xsk_build_skb() above the
overflow check so that the current descriptor's address is recorded
before a potential -EOVERFLOW jump to free_err, consistent with the
zerocopy path in xsk_build_skb_zerocopy().

[1]: https://lore.kernel.org/all/20260425041726.85FB3C2BCB2@smtp.kernel.org/

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


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

	Issue introduced in 6.6 with commit cf24f5a5feeaae34c1a34d1e04f8ac697290427a and fixed in 6.18.44 with commit 05e283466b86e0b25a5209a3eafe87aa9886064a
	Issue introduced in 6.6 with commit cf24f5a5feeaae34c1a34d1e04f8ac697290427a and fixed in 7.1.8 with commit a0528ab6af62bf57153caaf8ea28e5fcb0e18fd4
	Issue introduced in 6.6 with commit cf24f5a5feeaae34c1a34d1e04f8ac697290427a and fixed in 7.2-rc6 with commit a3c8382ebce4780c6b3ace2c09bc342313ac0186

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-74560
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:
	net/xdp/xsk.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/05e283466b86e0b25a5209a3eafe87aa9886064a
	https://git.kernel.org/stable/c/a0528ab6af62bf57153caaf8ea28e5fcb0e18fd4
	https://git.kernel.org/stable/c/a3c8382ebce4780c6b3ace2c09bc342313ac0186