Linux kernel mlx5e driver: Stale XSK buffer release on MPWQE refill retry
Summary
The Linux kernel driver for Mellanox/NVIDIA ConnectX NICs (net/mlx5e) can release AF_XDP zero-copy receive buffers a second time when a receive-ring refill fails with a memory allocation error and is retried. The retry can call xsk_buff_free() through stale pointers, which may corrupt memory and lead to a kernel crash or possibly privilege escalation. Exploitation requires a host with mlx5 NICs using AF_XDP zero-copy and an attacker able to drive allocation failures under memory pressure, which is hard to trigger on demand.
Affected
- Linux kernel versions from 6.4 onwards that include commit 4c2a1323680709078736a2886c754004e9fe42e6, up to the fixing commits listed in the CVE record.
- Vendor-listed unaffected ranges: 0 to before 6.4, 6.6.160 and later 6.6.x, 6.12.113 and later 6.12.x, 6.18.57 and later 6.18.x, 7.2.11 and later 7.2.x, 7.3 and later.
- Distribution kernels: Unknown.
Fixed in
- Upstream stable fixes: commits f3a52e2ec2788a7f6b64137985c087188a54ad4f, d215d09606b0fcd18ad1eb532995782a21cea49d, 867119b4b588037724b85839d534465f0334d9bd, 3d73a1164a8c6b4461907a65cb6c022ea4fd39af, 63811edf512584c946e5e96b100e9e280703bbb5.
- OSV lists fixed versions 6.6.160, 6.12.113, 6.18.57 and 7.2.11.
- Distribution fixes: Unknown. Ubuntu status was 'Needs evaluation' at the time of research.
Workaround
- No vendor-recommended workaround found.
- If AF_XDP zero-copy is not used on mlx5 NICs, the vulnerable path is not reached. Verify this with the application owners or with ss/bpftool before relying on it.
Exploitation
- No known in-the-wild exploitation.
- Not listed in the CISA KEV catalogue according to a third-party site (not directly verified).
- No public proof of concept found. The public material is the patch description.
- EPSS about 0.0046.
Our recommendation
- Inventory hosts with Mellanox/NVIDIA ConnectX NICs (lspci | grep -i mellanox, modinfo mlx5_core).
- Check whether any of these hosts run AF_XDP zero-copy workloads.
- Apply the kernel update from your distribution or the upstream stable fix for your branch as soon as it is available.
- If you use vendor-supplied OFED, track its backport status.
- Re-check the NVD entry, which was still in 'Received' status at the time of research.
Public exploits
PoC-in-GitHub, Metasploit and Exploit-DB list nothing for this CVE.
Research sources
- Linux stable commit 3d73a1164a8c6b4461907a65cb6c022ea4fd39af git.kernel.org
- Linux stable commit 63811edf512584c946e5e96b100e9e280703bbb5 git.kernel.org
- Linux stable commit 867119b4b588037724b85839d534465f0334d9bd git.kernel.org
- Linux stable commit d215d09606b0fcd18ad1eb532995782a21cea49d git.kernel.org
- Linux stable commit f3a52e2ec2788a7f6b64137985c087188a54ad4f git.kernel.org
- Ubuntu CVE tracker ubuntu.com
- OSV entry (Alpaquita) osv.dev
Researched and written up in English and German by an AI (Claude by Anthropic) based on NVD, CISA, EPSS and the sources listed. The vendor information is authoritative. Researched on 30 Oct 2026, 16:43.
Original description (NVD)
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Prevent stale XSK buffer release on MPWQE refill retry With AF_XDP on a striding RQ, mlx5e defers releasing XSK buffers until an MPWQE is refilled. If XSK allocation then returns -ENOMEM, actual_wq_head is not advanced and a later NAPI poll retries the same WQE. mlx5e_free_rx_mpwqe() leaves each released slot marked as releasable. On retry it can therefore call xsk_buff_free() again through stale pointers after the frames have returned to the XSK pool and been reallocated. Set all skip_release_bitmap bits in the common error path of mlx5e_xsk_alloc_rx_mpwqe(). This matches mlx5e_alloc_rx_mpwqe(). A successful allocation already clears the bitmap after replacing every buffer, so retries become idempotent without changing the success path. Fault injection forced three consecutive failures for one selected MPWQE. Both an early allocation failure and a partial 8-of-16-buffer unwind released the original 16 XSK buffers only once. Each error left a full bitmap, the following NAPI retry skipped the release, and a later successful allocation cleared it. A 20-second AF_XDP zero-copy pressure run exercised 1,575,262 buffer allocation failures without invalid descriptors, WQE errors, or kernel warnings.
NVD references (5)
- https://git.kernel.org/stable/c/3d73a1164a8c6b4461907a65cb6c022ea4fd39af
- https://git.kernel.org/stable/c/63811edf512584c946e5e96b100e9e280703bbb5
- https://git.kernel.org/stable/c/867119b4b588037724b85839d534465f0334d9bd
- https://git.kernel.org/stable/c/d215d09606b0fcd18ad1eb532995782a21cea49d
- https://git.kernel.org/stable/c/f3a52e2ec2788a7f6b64137985c087188a54ad4f
Sources
The tracker combines official, freely usable data sources – updated continuously:
- NVD (NIST) – CVEs, rating (CVSS), affected products
- CISA KEV – vulnerabilities confirmed by CISA as actively exploited
- CISA Vulnrichment – CISA assessment (SSVC) in the official CVE record
- FIRST EPSS – probability of exploitation
- Microsoft MSRC – Patch Tuesday: vulnerabilities, severity, updates
- PoC-in-GitHub – public proof-of-concept repositories
- Metasploit (Rapid7) – modules of the Metasploit Framework
- Exploit-DB (OffSec) – archive of public exploits (links only)
- Patch days: official vendor pages (linked per vendor) (Vendor patch days)
This product uses data from the NVD API but is not endorsed or certified by the NVD. EPSS data © FIRST.org.
Affected? We can help.
We check whether your systems are affected, install updates and close the gap – continuously with the System Health Checker if you wish.