Cloudanix VulnDB

CVE-2026-90242

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in how the Linux kernel manages certain device connections can leave behind small resource counts, eventually causing warning messages and possible instability when devices are removed.

Exploitation
Other
Attacker needs
High Privilege
Complexity
Theoretical
Impact
Other
Component
OS kernel
Class
Memory Corruption
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Reference count leak in IOMMU info->iopf_refcount during RID domain replacement prevents iopf_queue_remove_device and triggers WARN_ON on device release.

Why it matters to the business

Linux systems using Intel IOMMU may experience repeated kernel warnings, potential resource exhaustion over time, and operational instability during domain attach operations.

How an attack unfolds

An attacker with local access triggers repeated RID domain replacements on a device with an active iopf_handler; the missing iopf_for_domain_replace call in intel_iommu_attach_device and identity_domain_attach_dev leaks the reference each time until the WARN_ON fires on release.

How to fix it

Update to a kernel containing the fix that converts the two RID paths to use iopf_for_domain_replace; apply the latest stable kernel release that resolves the reference count handling.

How to confirm the fix worked

Confirm the presence of the iopf_for_domain_replace call in intel_iommu_attach_device and identity_domain_attach_dev; verify that iopf_refcount returns to zero on domain replacement and that no WARN_ON occurs on device release.

Typical attack path

  1. Obtain local code execution or driver privileges on affected Linux kernel
  2. Cause repeated attachment of domains that use IOPF handlers at RID level
  3. Trigger device_block_translation or identity_domain_attach_dev paths without proper replace handling
  4. Accumulate iopf_refcount leaks until device release produces kernel warning

How to detect it

Search kernel logs and dmesg for repeated iommu_disable_pci_pri WARN_ON messages referencing iopf_refcount; inspect IOMMU domain attach paths for devices undergoing frequent RID replacements.

What your security team should do

  • Prioritize kernel updates on systems exposing Intel IOMMU and PCI PRI features
  • Monitor kernel logs for iommu_disable_pci_pri WARN_ON messages
  • Test domain replacement workloads in staging before broad deployment

The record

In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix iopf_refcount leak on RID domain replacement intel_iommu_attach_device() enables IOPF for the new domain but never disables it for the old one. device_block_translation(), called at the start of the function, tears down translation but does not touch any IOPF state; blocking_domain_attach_dev() has to call iopf_for_domain_remove() explicitly before invoking it for exactly this reason. identity_domain_attach_dev() has the same problem. Its comment claims that no PRI handling is needed because the device has been put in the blocking state, but the blocking state and the IOPF reference count are independent of each other. As a result, replacing a domain that has an iopf_handler with another domain at RID level leaks a reference in info->iopf_refcount. The count never drops back to zero, so iopf_queue_remove_device() is never called and iommu_disable_pci_pri() triggers its WARN_ON(info->iopf_refcount) when the device is released. The PASID paths already handle this correctly by way of iopf_for_domain_replace(); convert the two RID paths to do the same. Using the replace helper rather than a bare remove keeps the enable before the disable, so the reference count does not transiently reach zero and evict the device from the IOPF queue.

Affected packages

Ecosystem Package Introduced Fixed