CVE-2026-72474 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: dma-axi-dmac: use DMA pool to manange DMA descriptor
For architectures like Microblaze or arm64 (where this IP is used), DMA_DIRECT_REMAP is set which means that dma_alloc_coherent() might remap (and hence vmalloc()) some memory. This became visible in a design where dma_direct_use_pool() is not possible.
With the above, when calling dma_free_coherent(), vunmap() would be called from softirq context and thus leading to a BUG().
To fix it, use a dma pool that is allocated in .device_alloc_chan_resources() and allocate blocks from it. The key point is that now dma_pool_free() is used in axi_dmac_free_desc() to free the blocks and that just frees the blocks from the pool in the sense they can be used again. In other words, no actual call to dma_free_coherent() happens. That only happens when destroying the pool in axi_dmac_free_chan_resources() which does not happen in any interrupt context.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/16/2026
The vulnerability resides within the Linux kernel's dmaengine subsystem, specifically affecting the dma-axi-dmac driver used on Microblaze and arm64 architectures where DMA_DIRECT_REMAP is enabled. This configuration causes dma_alloc_coherent() to potentially remap memory through vmalloc() operations, creating a critical operational conflict when dealing with interrupt contexts. The flaw manifests when the system attempts to free DMA coherent memory from softirq context, triggering an immediate kernel BUG() due to inappropriate memory management calls during interrupt handling.
The technical root cause stems from improper memory allocation and deallocation patterns within the AXI DMAC driver implementation. When DMA_DIRECT_REMAP is active on affected architectures, the standard dma_free_coherent() function cannot be safely invoked from softirq contexts because it internally calls vunmap(), which is forbidden in interrupt handlers according to kernel safety guidelines. This violates fundamental kernel design principles where interrupt contexts must avoid operations that could block or cause memory management complications. The vulnerability represents a classic case of context sensitivity failure in kernel space memory management, aligning with CWE-691 vulnerabilities related to insufficient control flow protection.
The operational impact of this vulnerability extends beyond simple system stability issues to potentially compromise entire system integrity on affected platforms. Systems utilizing Microblaze or arm64 architectures with AXI DMAC hardware components become susceptible to kernel panics and system crashes when DMA operations occur during interrupt processing. This affects embedded systems, real-time applications, and any environment where DMA transfers might be initiated from interrupt contexts, potentially leading to denial of service conditions that could persist until system reboot.
The fix implements a fundamental architectural change by replacing direct coherent DMA allocation with dedicated DMA pool management within the device allocation resources function. This approach ensures that all descriptor allocations occur through dma_pool_alloc() calls during channel initialization rather than through direct dma_alloc_coherent() operations. The solution maintains the same functional behavior while eliminating the problematic vunmap() calls from interrupt contexts, as demonstrated in the axi_dmac_free_desc() function. This mitigation strategy aligns with ATT&CK technique T1059.006 for kernel-level exploit prevention and addresses the underlying design flaw by establishing proper memory management boundaries that respect interrupt context constraints.
The implementation follows established best practices for kernel DMA subsystem management by utilizing the existing DMA pool infrastructure designed specifically to handle such scenarios. The solution ensures that actual dma_free_coherent() calls only occur during channel resource cleanup in non-interrupt contexts, completely eliminating the race condition and memory management conflict. This change maintains backward compatibility while providing robust protection against the specific class of vulnerabilities affecting interrupt-sensitive DMA operations. The approach demonstrates sound kernel security engineering principles by avoiding problematic memory management patterns rather than attempting to work around them through complex locking or scheduling mechanisms.