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.
Published: 2026-08-15
Score: 5.5 Medium
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The Linux kernel contains a defect in the DMA engine Axi‑DMAC implementation where a call to dma_free_coherent() can occur from a softirq context. Because the DMA channel uses DMA_DIRECT_REMAP, the allocated memory may live under vmalloc and freeing it in interrupt context triggers a vunmap() from a softirq, which is forbidden and causes a BUG() in the kernel. This defect can lead to a kernel panic or system crash if the DMA channel is exercised while the faulting condition exists.

Affected Systems

The bug is limited to Linux kernel configurations that enable the Axi‑DMAC driver on architectures such as Microblaze or arm64 where DMA_DIRECT_REMAP is active. No specific kernel version range is listed, so any build containing the affected driver code for those architectures is potentially vulnerable.

Risk and Exploitability

The CVSS score for this issue is not supplied in the current data set, but the EPSS score of 0.00209 indicates a very low probability of exploitation. Because the defect causes a kernel panic, it represents a high availability impact. The bug would only be triggered when the DMA engine is used under the specific scenario described, so the likelihood of exploitation without privileged local or remote access is low. The vulnerability is not listed in the CISA KEV catalogue, indicating that it is not a known actively exploited vulnerability at the time of this analysis.

Generated by OpenCVE AI on August 15, 2026 at 18:31 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Apply a kernel update that incorporates the fixed Axi‑DMAC DMA pool handling logic
  • Disable or unload the Axi‑DMAC driver on vulnerable devices until a patch is available
  • Enable system logging to capture kernel BUG() events that indicate this defect persists

Generated by OpenCVE AI on August 15, 2026 at 18:31 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Thu, 20 Aug 2026 00:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-663
References
Metrics threat_severity

None

cvssV3_1

{'score': 5.5, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'}

threat_severity

Moderate


Sat, 15 Aug 2026 19:00:00 +0000

Type Values Removed Values Added
Weaknesses CWE-404

Sat, 15 Aug 2026 06:00:00 +0000

Type Values Removed Values Added
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.
Title dmaengine: dma-axi-dmac: use DMA pool to manange DMA descriptor
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-08-17T05:15:23.275Z

Reserved: 2026-08-09T03:40:39.934Z

Link: CVE-2026-72474

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-08-15T06:22:21.563

Modified: 2026-08-17T06:19:15.430

Link: CVE-2026-72474

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-08-15T00:00:00Z

Links: CVE-2026-72474 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-08-16T02:00:16Z

Weaknesses
  • CWE-404

    Improper Resource Shutdown or Release

  • CWE-663

    Use of a Non-reentrant Function in a Concurrent Context