Linux kernel (drivers/iommu/intel): VT-d publishes the address of a freshly allocated PASID table into the PASID

CVSS 7.8CVE-2026-45862Kernel, userspace & hypervisorcurated

Impact

VT-d publishes the address of a freshly allocated PASID table into the PASID directory before that table's zeroed contents have been flushed to memory the IOMMU can see. In that window non-coherent IOMMU hardware walks whatever stale data occupied the page, treating old bytes as PASID entries - meaning a device translates through page-table roots that are not its own. Uncontrolled DMA from a passthrough device into host or other-tenant memory, which the vendor scores scope-changed.

Who can reach it

Any path that allocates a PASID table: enabling SVA/PASID for a tenant's device, or a VMM attaching a PASID-capable device through vfio/iommufd. Conditional on Intel VT-d scalable mode on a platform where the IOMMU is not cache-coherent for page-table walks. It is a timing window (the vendor vector marks AC:H), not a deterministic primitive.

What to do

Update to 5.10.252, 5.15.202, or 6.1.165 or later (or a newer stable series carrying the fix). Interim controls: do not enable SVA/PASID for tenant workloads on affected non-coherent VT-d platforms; keep PASID-capable device attach mediated by the host VMM.

References

https://git.kernel.org/stable/c/cd75e77125c8a51754ca4cd60b4ca083ed735d1d https://git.kernel.org/stable/c/0616137b70e6d9a547d4b60df8e1b64e36d83661 https://nvd.nist.gov/vuln/detail/CVE-2026-45862

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.