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

> A buffer leak in the Linux kernel's AF_XDP multi-buffer Tx path allows attackers to exhaust memory, causing denial of service.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Over the internet
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 15 Aug 2026
- **Updated:** 21 Oct 2026
- **Also known as:** AZL-96315, BELL-CVE-2026-74560, DEBIAN-CVE-2026-74560, GHSA-827x-m92x-hr38, UBUNTU-CVE-2026-74560

## What is CVE-2026-74560?

CVE-2026-74560 is a denial of service vulnerability in Linux, published on 15 Aug 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.

### Official 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/

## Which versions are affected by CVE-2026-74560?


## How do I fix CVE-2026-74560?

Apply the vendor's patch.

## Is CVE-2026-74560 being exploited?

There is no known exploitation of CVE-2026-74560 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2026-74560 and fix it if it is affected.

What it is: CVE-2026-74560 is a denial of service vulnerability in Linux, published on 15 Aug 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.
Exploitation: There is no known exploitation of CVE-2026-74560 in the wild and no public exploit code.

Affected product: Linux. No package-level version data is available, so check the vendor advisory linked from the reference page.

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2026-74560/ (Markdown: https://insights.sbomify.com/CVE-2026-74560/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2026-74560
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-74560
- OSV: https://osv.dev/vulnerability/CVE-2026-74560

---
From sbomify Insights: https://insights.sbomify.com/CVE-2026-74560/
Summaries are generated and may contain mistakes; the official description above is the record.