CVE-2026-74560

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xsk: fix buffer leak in xsk_drop_skb() for AF_XDP multi-buffer Tx<br /> <br /> This patch is inspired by the check[1] from sashiko. It says when<br /> overflow happens, the address of cq to be published is invalid.<br /> Actually the severer thing is the whole process of publishing the<br /> address of cq in this particular case is not right: it should truely<br /> publish the address and advance the cached_prod in cq as long as it<br /> reads descriptors from txq.<br /> <br /> The following is the full analysis.<br /> xsk_drop_skb() is called in three places, which all discard a partially<br /> built multi-buffer skb:<br /> 1) xsk_build_skb() -EOVERFLOW error path: packet exceeds MAX_SKB_FRAGS<br /> 2) __xsk_generic_xmit() post-loop cleanup: an invalid descriptor in<br /> the TX ring prevents the partial packet from completing<br /> 3) xsk_release(): socket close while xs-&gt;skb holds an incomplete packet<br /> <br /> In all three cases, the TX descriptors for the already-processed frags<br /> have been consumed from the TX ring (xskq_cons_release), and CQ slots<br /> have been reserved. However, xsk_drop_skb() calls xsk_consume_skb()<br /> which cancels the CQ reservations via xsk_cq_cancel_locked(). Since<br /> the buffer addresses never appear in the completion queue, userspace<br /> permanently loses track of these buffers.<br /> <br /> Fix this by letting consume_skb() trigger the existing xsk_destruct_skb<br /> destructor, which already submits buffer addresses to the CQ via<br /> xsk_cq_submit_addr_locked().<br /> <br /> Note that cancelling the descriptors back to the TX ring (via<br /> xskq_cons_cancel_n) is not a appropriate option because an oversized<br /> packet that always exceeds MAX_SKB_FRAGS would be retried indefinitely,<br /> which is an obviously deadlock bug in the TX path.<br /> <br /> Also move the desc-&gt;addr assignment in xsk_build_skb() above the<br /> overflow check so that the current descriptor&amp;#39;s address is recorded<br /> before a potential -EOVERFLOW jump to free_err, consistent with the<br /> zerocopy path in xsk_build_skb_zerocopy().<br /> <br /> [1]: https://lore.kernel.org/all/20260425041726.85FB3C2BCB2@smtp.kernel.org/