Linux kernel (drivers/iommu/amd): Iommu_completion_wait() returned without waiting whenever another CPU had already

Impact

Iommu_completion_wait() returned without waiting whenever another CPU had already queued a completion-wait, so a CPU could free page-table pages while the AMD IOMMU was still walking the translations those pages describe. The tenant's device then DMAs through a page table backed by memory the host has reallocated - a stale mapping that is a direct tenant-to-host DMA read/write escape, and the most serious bug in this batch.

Who can reach it

Any high-rate DMA map/unmap workload on an AMD-Vi host reaches it: a tenant hammering unmap through a passed-through NIC or GPU, or issuing VFIO_IOMMU_UNMAP_DMA in a loop from /dev/vfio/*, while a second CPU does concurrent IOMMU work. No host root, no fabric access; the race gets easier the busier the node is, so a co-tenant generating IOMMU traffic helps the attacker.

What to do

Update to a stable kernel carrying commits ab7faf5a / 93494bd4 on every AMD-Vi node. Interim controls are weak: reducing unmap rate or pinning tenants to fewer sockets only narrows the window. Treat this as a mandatory reboot on AMD hosts that run passthrough for tenants.

References