{"id":25651,"date":"2026-09-18T04:31:41","date_gmt":"2026-09-17T20:31:41","guid":{"rendered":"https:\/\/www.54iter.cn\/?vuln=cve-2026-90242"},"modified":"2026-09-18T04:31:41","modified_gmt":"2026-09-17T20:31:41","slug":"cve-2026-90242","status":"publish","type":"vuln","link":"https:\/\/www.54iter.cn\/?vuln=cve-2026-90242","title":{"rendered":"CVE-2026-90242 &#8211; In the Linux kernel, the following vulnerability has been resolved:\n\niommu\/vt-d: Fix iopf_"},"content":{"rendered":"<p>In the Linux kernel, the following vulnerability has been resolved:<\/p>\n<p>iommu\/vt-d: Fix iopf_refcount leak on RID domain replacement<\/p>\n<p>intel_iommu_attach_device() enables IOPF for the new domain but never<br \/>\ndisables it for the old one.  device_block_translation(), called at the<br \/>\nstart of the function, tears down translation but does not touch any IOPF<br \/>\nstate; blocking_domain_attach_dev() has to call iopf_for_domain_remove()<br \/>\nexplicitly before invoking it for exactly this reason.<\/p>\n<p>identity_domain_attach_dev() has the same problem.  Its comment claims<br \/>\nthat no PRI handling is needed because the device has been put in the<br \/>\nblocking state, but the blocking state and the IOPF reference count are<br \/>\nindependent of each other.<\/p>\n<p>As a result, replacing a domain that has an iopf_handler with another<br \/>\ndomain at RID level leaks a reference in info-&gt;iopf_refcount.  The count<br \/>\nnever drops back to zero, so iopf_queue_remove_device() is never called<br \/>\nand iommu_disable_pci_pri() triggers its WARN_ON(info-&gt;iopf_refcount)<br \/>\nwhen the device is released.<\/p>\n<p>The PASID paths already handle this correctly by way of<br \/>\niopf_for_domain_replace(); convert the two RID paths to do the same.<br \/>\nUsing the replace helper rather than a bare remove keeps the enable<br \/>\nbefore the disable, so the reference count does not transiently reach<br \/>\nzero and evict the device from the IOPF queue.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>In the Linux kernel, the following vulnerability has been resolved:<\/p>\n<p>iommu\/vt-d: Fix iopf_refcount leak on RID domain replacement<\/p>\n<p>intel_iommu_attach_device() enables IOPF for the new domain but never<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-25651","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/25651","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=25651"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=25651"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=25651"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}