CVE-2026-99028 in Linux
Summary
by MITRE • 10/23/2026
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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/23/2026
The Linux kernel driver for Xilinx AXI Ethernet interfaces contains critical resource management flaws that lead to memory leaks and race conditions during network interface shutdown operations. The vulnerability stems from an improper handling of Direct Memory Access buffer lifecycles within the dmaengine subsystem integration. Specifically, when a network interface is brought down via the ndo_stop operation, the driver invokes dmaengine_terminate_sync to abort pending descriptors. However, this termination process does not execute the associated completion callbacks that are responsible for cleaning up software-side resources such as socket buffers and their corresponding DMA mappings. Consequently, while the hardware descriptor rings may be cleared or reset, any transmit or receive buffer currently in flight remains allocated but orphaned from the driver's tracking mechanisms. This results in a persistent leak of kernel memory and IOMMU address space mappings every time the interface is toggled off.
The operational impact of this flaw is particularly severe due to the architecture of the AXI Ethernet controller, which pre-allocates a significant number of receive buffers per channel to maintain high throughput performance. With one hundred twenty-eight RX buffers typically pre-posted for each DMA channel, the failure to unmap and free these descriptors upon interface shutdown leads to an accumulation of unmapped but still reserved IOMMU aperture entries. Over time, particularly in environments where network interfaces are frequently brought up and down, this leak can exhaust the limited IOMMU address space available to the device or system. Such exhaustion prevents new DMA mappings from being established, effectively causing a denial of service for network connectivity on that interface until a full system reboot occurs to clear the stale mappings.
Beyond the resource leakage, the driver implementation suffers from a dangerous race condition between the DMA completion tasklet and the interface stop routine. The receive callback function axienet_dma_rx_cb executes in interrupt context via a tasklet and is responsible for re-arming the RX ring with new buffers upon each packet completion. There exists a window where this callback can submit a fresh buffer after dmaengine_terminate_sync has returned but before the channel release completes. Because dma_release_channel does not immediately halt hardware activity, the engine may continue to write into memory that the teardown process is simultaneously attempting to free and unmap. This race condition creates a use-after-free scenario or data corruption risk, as the kernel frees resources while they are still actively being accessed by DMA operations.
The resolution involves implementing strict synchronization mechanisms to ensure atomicity during state transitions between active operation and shutdown. The fix introduces a stopping flag that is protected by a mutex lock held across critical sections in both the callback and stop routines. In the receive callback, the driver checks this flag before arming new buffers; if the interface is marked as stopping, no new DMA submissions are permitted. Simultaneously, axienet_stop acquires the same lock to set the stopping flag before invoking dmaengine_terminate_sync. This ensures that once termination begins, no new in-flight descriptors can be created, and any buffer submitted immediately prior is safely aborted by the terminate call. Furthermore, the cleanup logic is enhanced to explicitly iterate through all slots marked as having live DMA mappings during shutdown, ensuring every outstanding SKB is properly unmapped from IOMMU contexts and freed from kernel memory pools before the channel is released.
From a vulnerability classification perspective, this issue aligns with CWE-401 Missing Release of Memory after Effective Lifetime, as resources are not reclaimed when they become inaccessible or obsolete during interface teardown. The race condition component relates to CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization, specifically involving the lack of proper locking around shared state variables that control DMA buffer lifecycle management. In terms of attack surface and behavior mapping under MITRE ATT&CK for Enterprise, this vulnerability falls under T1529 System Shutdown or Reboot Implications if exploited to cause denial of service through resource exhaustion, although it is primarily a stability issue rather than an exploitable security flaw in the traditional sense. The remediation emphasizes robust state machine design and explicit cleanup routines that are decoupled from hardware completion paths to prevent dangling references and memory leaks in high-performance network drivers.