CVE-2026-90242

/// Technical 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

/// Remediation

Check the references section for vendor advisories, patches, and mitigation guidance. If immediate patching is not possible, review the CVSS vector to understand the attack surface and apply compensating controls such as network segmentation or access restrictions.

/// References