ZeroDay Findings
Sign inSign up

Vulnerabilities

Vulnerability · CVE-2026-90242

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 IO…

Published Sep 17, 2026 · catalog updated Oct 15, 2026 · the affected product

Check if you run it

No confirmed exploitation is on record for CVE-2026-90242. EPSS is 0.21%. Act only if a listed version of the affected product is installed.

Severity
Unknown—
Known exploitation
Not in CISA/VulnCheck KEV
EPSS
0.21%
Remediation
Not established
Affected products
See sources for product scope

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.

No affected version ranges are stored yet. Use the vendor advisory before you decide this record does not apply.

How to fix CVE-2026-90242

What to do

Three questions, each answered from this record only. Confirm the vendor advisory before you patch.

Should you patch?

No confirmed exploitation is on record for CVE-2026-90242. EPSS is 0.21%. Act only if a listed version of the affected product is installed.

Which versions are affected?

Affected version ranges are not on this record. Compare the installed version with the linked vendor advisory before you change production.

What should an analyst verify?

No weakness class is stored. EPSS 0.21%. There is no CISA KEV listing. No Exploit-DB or Metasploit reference is linked. Use the source links for the original advisory.

Code

The project this record applies to. Exploit listings stay in References.

Timeline

Detection, updates, and resolution for this record.

  1. Sep 17, 2026 · NIST NVD

    Detected

    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

  2. Oct 15, 2026 · NIST NVD

    Updated

    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

Sources

  • CVE.orgVulnerability recordCVE-2026-90242

    Official CVE identifier

    cve.org
  • FIRST EPSSExploitation probabilityCVE-2026-90242

    30-day exploitation probability 0.2%

    first.org
  • NIST NVDVulnerability recordCVE-2026-90242

    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 o

    nvd.nist.gov

References

Freshness

Last verified in this catalog Oct 18, 2026. Significant claims (KEV, EPSS, CVSS, affected ranges) come from the source rows above — open the original publisher for the authoritative advisory.