GPU VulnDB

Database/Kernel, userspace & hypervisor

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

CVSS 8.8CVE-2026-68329Kernel, userspace & hypervisorcurated

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

https://git.kernel.org/stable/c/ab7faf5a172ebfdc423ebb3eea4d472740de82f9https://git.kernel.org/stable/c/93494bd446396c257fb589f59894577e96e406e2https://nvd.nist.gov/vuln/detail/CVE-2026-68329

Related entries

All Kernel, userspace & hypervisor entries

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.