Answer in brief
CVE-2026-72474 records a Unknown severity vulnerability in dmaengine: dma-axi-dmac: use DMA pool to manange DMA descriptor. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=3f8fd25936ee5f52596f10d420f650c5b5e3285f <a4f41ceecfe68e117bae9c76c5ebc5e2b353fa56 || >=3f8fd25936ee5f52596f10d420f650c5b5e3285f <c0e6bb2b0408fcac6382158ee2bd9fdc45eceee9 || >=3f8fd25936ee5f52596f10d420f650c5b5e3285f <65e82fa24965b2eb6ad9412f6c530ed9a50a625f || >=3f8fd25936ee5f52596f10d420f650c5b5e3285f <9e942c8579130e62734c14338e9f451780669164 | a4f41ceecfe68e117bae9c76c5ebc5e2b353fa56, c0e6bb2b0408fcac6382158ee2bd9fdc45eceee9, 65e82fa24965b2eb6ad9412f6c530ed9a50a625f, 9e942c8579130e62734c14338e9f451780669164 |
| Linux/Linuxgeneric | 6.8 | Not reported |
Published upstream
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 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.
Quoted source text, attributed separately from HOL analysis.
Answer in brief
CVE-2026-72474 records a Unknown severity vulnerability in dmaengine: dma-axi-dmac: use DMA pool to manange DMA descriptor. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=3f8fd25936ee5f52596f10d420f650c5b5e3285f <a4f41ceecfe68e117bae9c76c5ebc5e2b353fa56 || >=3f8fd25936ee5f52596f10d420f650c5b5e3285f <c0e6bb2b0408fcac6382158ee2bd9fdc45eceee9 || >=3f8fd25936ee5f52596f10d420f650c5b5e3285f <65e82fa24965b2eb6ad9412f6c530ed9a50a625f || >=3f8fd25936ee5f52596f10d420f650c5b5e3285f <9e942c8579130e62734c14338e9f451780669164 | a4f41ceecfe68e117bae9c76c5ebc5e2b353fa56, c0e6bb2b0408fcac6382158ee2bd9fdc45eceee9, 65e82fa24965b2eb6ad9412f6c530ed9a50a625f, 9e942c8579130e62734c14338e9f451780669164 |
| Linux/Linuxgeneric | 6.8 | Not reported |
Published upstream
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 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.
Quoted source text, attributed separately from HOL analysis.