CVE-2026-90242: iommu/vt-d: Fix iopf_refcount leak on RID domain replacement
In the Linux kernel, the following vulnerability has been resolved:
iommu/vt-d: Fix iopfrefcount leak on RID domain replacement
inteliommuattachdevice() enables IOPF for the new domain but never disables it for the old one. deviceblocktranslation(), called at the start of the function, tears down translation but does not touch any IOPF state; blockingdomainattachdev() has to call iopffordomainremove() explicitly before invoking it for exactly this reason.
identitydomainattachdev() 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 iopfhandler with another domain at RID level leaks a reference in info->iopfrefcount. The count never drops back to zero, so iopfqueueremovedevice() is never called and iommudisablepcipri() triggers its WARNON(info->iopfrefcount) when the device is released.
The PASID paths already handle this correctly by way of iopffordomainreplace(); 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 Software
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
The issue affects Linux kernel systems using the Intel VT-d IOMMU driver where a device's RID-level domain is replaced and the original domain has an IOPF handler. The affected paths are the RID domain replacement flows used by intel_iommu_attach_device() and identity_domain_attach_dev().
What conditions are required to trigger the leak?
A RID-level domain with an IOPF handler must be replaced by another domain. The old domain's IOPF state is not removed in the vulnerable paths, leaving a reference in info->iopf_refcount.
How could an administrator recognize that the condition has occurred?
When the affected device is released, iommu_disable_pci_pri() can trigger a WARN_ON for info->iopf_refcount. The stale nonzero reference also prevents iopf_queue_remove_device() from being called.
What does the fix change?
The RID-level replacement paths are changed to use iopf_for_domain_replace(), consistent with the existing PASID paths. This removes the old domain's IOPF state while enabling it for the replacement domain.