Strix
56.2K

CVE-2026-72474

UnknownEPSS 0.21%

Last modified

CVE-2026-72474 is a vulnerability of currently unknown severity. 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. EPSS estimates a 0.21% chance of exploitation in the next 30 days.

Description

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.

Metrics

EPSS Probability
0.21%

11.4th percentile

Probability of exploitation in the next 30 days. Learn more

Affected Software

Source: CNA advisory (CVE.org). NVD analysis pending.

VendorProductVersions
LinuxLinux>= 3f8fd25936ee5f52596f10d420f650c5b5e3285f, < a4f41ceecfe68e117bae9c76c5ebc5e2b353fa56; >= 3f8fd25936ee5f52596f10d420f650c5b5e3285f, < c0e6bb2b0408fcac6382158ee2bd9fdc45eceee9; >= 3f8fd25936ee5f52596f10d420f650c5b5e3285f, < 65e82fa24965b2eb6ad9412f6c530ed9a50a625f; >= 3f8fd25936ee5f52596f10d420f650c5b5e3285f, < 9e942c8579130e62734c14338e9f451780669164
LinuxLinux6.8

References

Timeline

Published
Last Modified
Status
Received

Frequently Asked Questions

What is CVE-2026-72474?
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.
How severe is CVE-2026-72474?
Severity scoring for CVE-2026-72474 is pending analysis. The EPSS model estimates a 0.21% probability of exploitation in the next 30 days.
How do I fix CVE-2026-72474?
Check the vendor references and advisories linked above for patched versions and mitigation guidance. You can also run a Strix scan to test if your systems are affected.

How Strix Helps

Related CVEs from 2026

View all 2026CVEs →

Are you affected by CVE-2026-72474?

Run a free Strix scan to check your systems for this vulnerability.

Scan your code now

Source: NVD / NIST