CVE-2026-90242 iommu/vt-d: Fix iopf_refcount leak on RID domain replacement
A reference count leak in the Linux kernel IOMMU driver can cause a warning and potential resource exhaustion when replacing device domains.
- Exploited in the wild
- Not known
- Login needed
- An administrator
- Attackable
- Local or same network only
- Victim action needed
- Not needed
- Fix
- Available
What is CVE-2026-90242?
CVE-2026-90242 is a denial of service vulnerability in Linux, published on 17 Sep 2026. It can only be exploited from the same machine or local network, with no action from the victim.
Official description
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.
Which versions are affected by CVE-2026-90242?
How do I fix CVE-2026-90242?
Apply the vendor's patch.
Upgrade, then put limits on request size, rate and nesting depth so one client cannot exhaust the service. More about Denial of service.
Is CVE-2026-90242 being exploited?
There is no known exploitation of CVE-2026-90242 in the wild and no public exploit code.
Sources
Also known as BELL-CVE-2026-90242, DEBIAN-CVE-2026-90242, GHSA-f898-qwj6-vcxv, UBUNTU-CVE-2026-90242.