Cloudanix VulnDB

CVE-2026-90388

High · 7.8

CVSS

7.8

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

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

  1. Obtain local user access on a Linux system using the vulnerable iommu/dma code path
  2. Trigger a non-blocking non-coherent DMA allocation that exhausts or fails the atomic pool
  3. Force the kernel to evaluate the allocation result via the faulty cpu_addr check
  4. Proceed with IOMMU mapping using the unchecked/invalid address
  5. 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