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/
Published: 2026-08-15
Score: 5.5 Medium
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The flaw resides in the Linux kernel’s AF_XDP implementation, where the function that discards partially built multi-buffer packets mistakenly cancels completion queue slots, preventing the kernel from reclaiming memory pages that were already advanced in the transmission ring. This results in a permanent loss of those buffers in user space, causing a gradual depletion of available descriptors. Over time the system can run out of buffers, degrading performance or leading to a denial‑of‑service for high‑throughput, zero‑copy networking applications.

Affected Systems

All Linux kernel releases that contain the buggy xsk_drop_skb() logic are susceptible; kernel variants that incorporate the upstream commit 05e283466b86e0b25a5209a3eafe87aa9886064a and its successors are not affected. The issue is specific to the AF_XDP portion of the kernel, which is used by applications requiring high‑performance packet I/O.

Risk and Exploitability

The CVSS score of 5.5 and an EPSS score of <1% suggest a moderate severity with a low likelihood of exploitation, and the vulnerability is not listed in the CISA KEV catalog. Based on the description, it is inferred that an attacker can trigger the buffer leak by creating or manipulating AF_XDP sockets to send oversized packets that exceed MAX_SKB_FRAGS or inject invalid TX descriptors, thereby causing the kernel to discard part of a packet and leave buffers unreclaimed. This local or remote exploitation path may be accessible to non‑privileged users on systems that expose AF_XDP support, and the resulting resource exhaustion represents a moderate‑to‑high risk on servers that rely heavily on AF_XDP for high‑performance networking.

Generated by OpenCVE AI on August 21, 2026 at 21:57 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Apply a kernel update that includes the AF_XDP buffer‑leak fix and verify the running version.
  • If a kernel upgrade cannot be applied immediately, avoid creating AF_XDP sockets that handle packets larger than MAX_SKB_FRAGS and handle EOVERFLOW errors gracefully.
  • As a temporary measure, restart affected services or reboot the host to clear the leaked descriptor pool while monitoring buffer usage for signs of exhaustion.

Generated by OpenCVE AI on August 21, 2026 at 21:57 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Fri, 21 Aug 2026 20:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-400
CWE-701

Thu, 20 Aug 2026 00:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-771
References
Metrics threat_severity

None

 cvssV3_1

{'score': 5.5, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'}

threat_severity

Low

Sat, 15 Aug 2026 15:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-400
CWE-701

Sat, 15 Aug 2026 12:45:00 +0000

Type Values Removed Values Added
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/
Title xsk: fix buffer leak in xsk_drop_skb() for AF_XDP multi-buffer Tx
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-08-17T05:21:47.344Z

Reserved: 2026-08-15T05:44:03.916Z

Link: CVE-2026-74560

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-08-15T13:18:01.483

Modified: 2026-08-17T06:19:54.100

Link: CVE-2026-74560

cve-icon Redhat

Severity : Low

Publid Date: 2026-08-15T00:00:00Z

Links: CVE-2026-74560 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-08-21T22:00:14Z

Weaknesses
  • CWE-771

    Missing Reference to Active Allocated Resource