Linux kernel VT-d: ACS not requested under tboot, leaving peer-to-peer DMA isolation off

UnscoredCVE-2026-89448Kernel, userspace & hypervisorcurated

Impact

detect_intel_iommu() did not consider tboot when deciding to request PCIe Access Control Services, so a host where the user disabled ACS via boot options but tboot later forces the IOMMU on ends up running with the IOMMU enabled and ACS off. Without ACS, peer-to-peer traffic between PCIe devices can bypass IOMMU translation, which is the isolation that keeps a passed-through GPU or NIC from reaching another device's memory. On a multi-tenant node doing device passthrough this is a silent weakening of the boundary the operator believes they have, not a crash. Exposure is limited to Intel hosts that actually boot with tboot and an ACS-disabling option.

Who can reach it

Requires a device already under a tenant's control on an affected host (passthrough GPU, NIC or DPU) to abuse the missing peer-to-peer isolation. Not remotely reachable; the flaw is a host boot-time misconfiguration.

What to do

Update to a stable kernel with the tboot check and reboot the affected hosts. As an interim check, verify on tboot systems whether ACS is actually enabled before relying on device isolation for passthrough. No fixed release numbers are given beyond the linked stable commits.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-89448 https://git.kernel.org/stable/c/45705a6bfdb283f7b3b509010fd617b72f942537 https://git.kernel.org/stable/c/607432b2618b61df81134be0ef2562b8300c1216 https://git.kernel.org/stable/c/87bc611c6c98a41c00feb7b06b0c297dd141a2ae

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.