CVE-2026-90242 in Linux
Summary
by MITRE • 09/17/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel contains a resource management flaw within the Intel VT-d IOMMU driver specifically affecting Requester ID domain replacements. This vulnerability manifests as an integer overflow or logical leak in the Input/Output Page Fault reference counting mechanism, technically classified under CWE-401 Missing Release of Resource after Effective Lifetime. The core issue resides in two specific functions: intel_iommu_attach_device and identity_domain_attach_dev. When a device's domain is replaced at the Requester ID level, these functions enable IOPF for the new domain but fail to disable it for the old one. Although device_block_translation is invoked early in the process to tear down translation contexts, this operation does not interact with or reset any IOPF state variables. Consequently, the reference count associated with the previous domain remains elevated because blocking_domain_attach_dev requires an explicit call to iopf_for_domain_remove which was omitted in these code paths.
The operational impact of this flaw is a persistent memory and resource leak that degrades system stability over time. Because the IOPF reference count never drops back to zero, the kernel fails to invoke iopf_queue_remove_device for the affected device. This prevents proper cleanup of the fault handling queue entries associated with the old domain. Eventually, when the device is released or detached from the system entirely, the function iommu_disable_pci_pri executes a sanity check via WARN_ON that verifies whether info->iopf_refcount has reached zero. Since the count remains non-zero due to the leak, this warning triggers, indicating an inconsistent internal state and potential for resource exhaustion if such domain replacements occur frequently across multiple devices in a virtualized or multi-tenant environment.
The PASID path within the same driver correctly handles this scenario by utilizing iopf_for_domain_replace which ensures proper reference counting adjustments during transitions. The fix aligns the RID paths with this established pattern, ensuring that the enable operation for the new domain precedes the disable operation for the old one. This ordering is critical because it prevents the reference count from transiently reaching zero, which could otherwise cause premature eviction of the device from the IOPF queue before all necessary cleanup operations are completed. By adopting the replace helper instead of a bare remove sequence, the kernel maintains atomicity in state transitions and preserves data integrity within the fault handling subsystem.
From a security perspective, this vulnerability aligns with ATT&CK techniques related to resource exhaustion and potential denial of service through improper resource management. While primarily a stability issue rather than an arbitrary code execution vector, persistent leaks can lead to system instability or crashes under heavy I/O workloads involving frequent domain changes. Mitigation involves applying the kernel patch that updates intel_iommu_attach_device and identity_domain_attach_dev to correctly call iopf_for_domain_remove before attaching new domains. System administrators should ensure their Linux kernels are updated to versions containing this fix, particularly in environments utilizing Intel VT-d with dynamic device assignment or virtualization features that trigger frequent domain replacements. Regular monitoring of kernel logs for WARN_ON messages related to PCI PRI can help detect instances where the leak has manifested prior to patching.