Linux kernel (drivers/iommu/generic_pt): When an unmap lands in the middle of a large or contiguous page-table entry

Impact

When an unmap lands in the middle of a large or contiguous page-table entry the kernel unmaps more than was requested but only invalidates the range that was requested. The extra IOVAs stay live in the IOMMU TLB, so a passthrough device keeps a working DMA window into pages the kernel has already handed back to the allocator. That is a direct tenant-to-host DMA escape: the device can read and write whatever lands in those pages next. Note the upstream author's own caveat that he knows of nothing that currently unmaps a large entry this way, so he believes it is not triggerable in practice - the vendor still scores it 8.8 scope-changed.

Who can reach it

Whichever side drives the unmap: a VMM's IOMMU_IOAS_UNMAP on /dev/iommu, or an in-kernel driver DMA unmap. Conditional on the generic page-table (iommupt) backend being in use and on the mapping having been built with large or contiguous IOPTEs, and on the unmap boundary falling inside one of them. Not reachable from the network fabric.

What to do

The record lists no fixed release; boot a kernel carrying the stable fix commits below. There is no useful interim control for a stale-TLB bug other than the patched kernel - do not rely on unmapping as a security boundary until the node is patched.

References