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.
Published: 2026-09-17
Score: n/a
EPSS: < 1% Very Low
KEV: No
Impact: Resource Leak potentially leading to denial of service
Action: Update Kernel
AI Analysis

Impact

The Linux kernel iommu/vt‑d code contains a reference‑counting flaw that prevents the IOPF (I/O Protection Filter) from being disabled when a domain is replaced at the RID level. The iopf_refcount therefore never decrements to zero, causing iopf_queue_remove_device() to never be called and triggering a WARN_ON during device release. This leak can accumulate over time, potentially exhausting internal queues or repeatedly generating warning messages, leading to system instability or a denial of service. The weakness is a reference‑counting error (CWE‑391).

Affected Systems

All Linux kernel builds that include the pre‑fix iommu/vt‑d implementation, regardless of the specific version number. The vulnerability was present before the commit that introduced the iopf_refcount fix. Any kernel that shipped the older code and has not yet applied the patch may be susceptible.

Risk and Exploitability

The EPSS score is reported as less than 1%, indicating a low probability of exploitation. The vulnerability is not listed in the CISA KEV catalog. The description shows that the flaw is triggered when a domain is replaced, a capability that typically requires kernel or root privileges. Based on this, it is inferred that the attack vector is local and requires elevated access, so the risk to unprivileged users is minimal.

Generated by OpenCVE AI on September 19, 2026 at 15:12 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Apply the Linux kernel patch that contains the iopf_refcount fix.
  • Configure automated alerts for WARN_ON messages involving iopf_refcount in system log monitoring tools.
  • Perform a deliberate domain replacement test after patch deployment to verify that the WARN_ON does not trigger, confirming the leak is resolved.

Generated by OpenCVE AI on September 19, 2026 at 15:12 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Sat, 19 Sep 2026 15:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-391

Thu, 17 Sep 2026 16:30:00 +0000

Type Values Removed Values Added
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.
Title iommu/vt-d: Fix iopf_refcount leak on RID domain replacement
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-09-17T16:07:45.817Z

Reserved: 2026-09-11T19:38:34.795Z

Link: CVE-2026-90242

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-09-17T17:17:20.190

Modified: 2026-09-17T17:17:20.190

Link: CVE-2026-90242

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-19T15:15:14Z

Weaknesses
  • CWE-391

    Unchecked Error Condition