CVE-2026-90388
High · 7.8CVSS
7.8
EPSS
0.2%
Published
Sep 17, 2026
CISA due date
—
Cloudanix analysis
A mistake in how the Linux kernel checks for memory allocation failures when talking to certain hardware devices could let someone already on the system take over the whole machine.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- Low
- Impact
- Full Compromise
- Component
- OS kernel
- Class
- Improper Input Validation
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
The vulnerability stems from relying on a cpu_addr pointer to infer dma_alloc_from_pool() failure instead of checking the returned page pointer directly; on allocation failure the code proceeds to use an invalid or stale address for IOMMU mapping, resulting in improper input validation that can cause memory corruption, invalid pointer dereference, or kernel-level data exposure.
Why it matters to the business
Local attackers with low privileges can achieve full system compromise including arbitrary code execution, data theft, or denial of service on affected Linux systems; the stable low EPSS and lack of known exploitation reduce immediate external risk but do not eliminate the need for prompt patching in environments running vulnerable kernels.
How an attack unfolds
An attacker with local access crafts or triggers a non-blocking, non-coherent DMA allocation that fails inside dma_alloc_from_pool(); because the caller checks cpu_addr rather than the returned page, execution continues with an invalid address, allowing the attacker to influence the subsequent IOMMU mapping operation and corrupt kernel memory or leak sensitive data.
How to fix it
Update the Linux kernel to a version containing the fix that checks the page pointer returned by dma_alloc_from_pool() directly before use; apply the patch or newer kernel release as soon as vendor packages become available.
How to confirm the fix worked
Confirm the kernel source contains the corrected check for the page return value from dma_alloc_from_pool() rather than cpu_addr; recompile or install the updated kernel and verify the allocation failure path now returns early without proceeding to IOMMU mapping on error.
Typical attack path
- Obtain local user access on a Linux system using the vulnerable iommu/dma code path
- Trigger a non-blocking non-coherent DMA allocation that exhausts or fails the atomic pool
- Force the kernel to evaluate the allocation result via the faulty cpu_addr check
- Proceed with IOMMU mapping using the unchecked/invalid address
- Leverage resulting memory corruption or pointer misuse for privilege escalation or information disclosure
How to detect it
Review kernel logs for unexpected DMA allocation failures or IOMMU mapping errors around the time of suspected activity; examine audit logs for unusual local process behavior involving DMA or IOMMU operations; no public exploit artifacts are known.
What your security team should do
- Prioritize kernel updates for all systems exposing IOMMU/DMA functionality
- Monitor upstream Linux kernel changelogs for backports to supported distribution kernels
- Restrict local unprivileged access where feasible until patches are deployed
- Test updated kernels in staging environments before broad rollout
The record
In the Linux kernel, the following vulnerability has been resolved: iommu/dma: Check atomic pool allocation result directly The non-blocking, non-coherent allocation path uses dma_alloc_from_pool(), which returns the allocated page and fills cpu_addr only on success. Do not rely on cpu_addr to detect allocation failure in this path. Check the returned page directly before using it for the IOMMU mapping.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|