CVE-2026-90242
Last modified
CVE-2026-90242 is a vulnerability of currently unknown severity. 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.
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.
Affected Software
Source: CNA advisory (CVE.org). NVD analysis pending.
| Vendor | Product | Versions |
|---|---|---|
| Linux | Linux | >= 17fce9d2336d952b95474248303e5e7d9777f2e0, < 143cd37ce76527ddd6f6dbac4a89bde31fb8b0dc; >= 17fce9d2336d952b95474248303e5e7d9777f2e0, < 236dd58fabd2e951b940a6ad88b81147899ed311 |
| Linux | Linux | 6.16 |
References
Timeline
- Published
- Last Modified
- Status
- Received
Frequently Asked Questions
What is CVE-2026-90242?
How severe is CVE-2026-90242?
How do I fix CVE-2026-90242?
How Strix Helps
- How Strix found a critical auth bypass in etcdStrix autonomously discovered a critical authentication bypass in etcd, later designated CVE-2026-33413.
- Autonomous PentestingAI agents that find and validate exploitable vulnerabilities like this one across your applications.
- PR ReviewsPentest every pull request so vulnerable code is caught before it ships to production.
- AI Penetration TestingHow AI-driven penetration testing continuously covers your attack surface.
Related CVEs from 2026
- CVE-2026-90237In the Linux kernel, the following vulnerability has been re…7.8
- CVE-2026-90238In the Linux kernel, the following vulnerability has been re…
- CVE-2026-90239In the Linux kernel, the following vulnerability has been re…
- CVE-2026-9024A Stored Cross-site Scripting (XSS) vulnerability affecting …8.7
- CVE-2026-90240In the Linux kernel, the following vulnerability has been re…8.8
- CVE-2026-90241In the Linux kernel, the following vulnerability has been re…8.2
- CVE-2026-90243In the Linux kernel, the following vulnerability has been re…8.1
- CVE-2026-90244In the Linux kernel, the following vulnerability has been re…7.8
- CVE-2026-90245In the Linux kernel, the following vulnerability has been re…
- CVE-2026-90246In the Linux kernel, the following vulnerability has been re…7.1
- CVE-2026-90247In the Linux kernel, the following vulnerability has been re…
- CVE-2026-90248In the Linux kernel, the following vulnerability has been re…
Are you affected by CVE-2026-90242?
Run a free Strix scan to check your systems for this vulnerability.
Scan your code nowSource: NVD / NIST
