Cloudanix VulnDB

CVE-2026-90241

High · 8.2

CVSS

8.2

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A programming mistake in the Linux kernel's handling of certain hardware devices can let a privileged local user corrupt memory and crash or take over the machine.

Exploitation
Local Privilege
Attacker needs
High Privilege
Complexity
Moderate
Impact
Full Compromise
Component
OS kernel
Class
Use After Free
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Probe failure in intel_iommu_probe_device leaves scalable-mode context entries programmed for some DMA aliases while the associated PASID table is freed, allowing the IOMMU to dereference a pointer into released memory on subsequent translations.

Why it matters to the business

Local attackers with sufficient privileges can trigger kernel memory corruption on systems using Intel VT-d scalable mode, potentially leading to system instability, privilege escalation, or denial of service on affected Linux hosts.

How an attack unfolds

An attacker crafts a PCI device configuration or triggers a probe path that causes intel_pasid_setup_sm_context to succeed for the first alias but fail on a later one; the error path frees the PASID table without clearing the already-written context entries, so a subsequent IOMMU walk uses the dangling pointer.

How to fix it

Update the Linux kernel to a version that contains the fix ensuring device_pasid_table_teardown runs before intel_pasid_free_table on all probe-failure paths; apply the vendor-supplied patch that aligns probe-error handling with the ordering already present in intel_iommu_release_device.

How to confirm the fix worked

Confirm the kernel source contains the call to device_pasid_table_teardown prior to the free on the intel_iommu_probe_device error path; verify that iommu_context_addr returns NULL for unprogrammed RIDs and that Present-bit clearing is a no-op for absent entries.

Typical attack path

  1. Obtain local access with privileges required to trigger IOMMU device probe or alias configuration changes
  2. Force a probe failure partway through pci_for_each_dma_alias for a device that has multiple DMA aliases
  3. Trigger IOMMU page-table walks or DMA operations that cause the hardware to follow the stale context entry
  4. Leverage the resulting use-after-free for memory corruption or control-flow hijacking

How to detect it

Review kernel logs for IOMMU and VT-d error paths around device probe failures; look for unexpected oops or warnings referencing pasid table teardown or context entry handling; examine crash dumps for use-after-free signatures in iommu/vt-d code paths.

What your security team should do

  • Prioritize kernel updates on all systems that expose Intel VT-d scalable-mode IOMMU to untrusted devices or drivers
  • Monitor vendor advisories for backported fixes in supported distribution kernels
  • Restrict unprivileged access to PCI device configuration interfaces where feasible until patches are deployed

The record

In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Tear down scalable-mode context on probe failure intel_pasid_setup_sm_context() walks a PCI device’s DMA aliases via pci_for_each_dma_alias() and programs a scalable-mode context entry for each RID. For a device with a dma_alias_mask, the callback is invoked once for the device’s own RID and once for each alias bit, all with the same pci_dev, so device_pasid_table_setup() runs for multiple RIDs. pci_for_each_dma_alias() stops at the first callback error. Therefore, a failure partway through the walk can leave context entries for already processed RIDs present and still pointing to the device’s PASID table. On this error path, intel_iommu_probe_device() currently jumps directly to intel_pasid_free_table(), which frees the PASID table without first tearing down those context entries. The IOMMU may then walk a present context entry whose PASID table pointer references freed memory. intel_iommu_release_device() already performs teardown before freeing the table. Apply the same ordering on the probe failure path. device_pasid_table_teardown() safely handles RIDs that were never programmed: iommu_context_addr() returns NULL when no context table has been allocated, and clearing the Present bit of an already non-present entry is a no-op. So unwind is safe for both the alias that failed and any aliases not yet reached.

Affected packages

Ecosystem Package Introduced Fixed