Linux kernel (drivers/iommu/iommufd): The IOVA allocator's alignment arithmetic wraps near ULONG_MAX and yields a

Impact

The IOVA allocator's alignment arithmetic wraps near ULONG_MAX and yields a corrupted IOVA. The upstream fix states it plainly - userspace can create a mapping that overlaps an existing mapping or a reserved range. That is an over-broad DMA window: a tenant's passthrough device gets translations into memory the IOMMU was supposed to be fencing off, including ranges reserved for MSI and for other domains. This is the direct tenant-to-host DMA escape shape.

Who can reach it

A tenant holding /dev/iommu issues IOAS map/allocate requests with a length and alignment chosen so the candidate range sits near the top of the address space and the alignment rounds past ULONG_MAX. No host root, no special hardware - just the iommufd ioctls a passthrough tenant already uses to program its own DMA mappings. Conditional on iommufd being the passthrough path on the node.

What to do

Apply the linked stable commits or run a current stable/LTS kernel on every node that exposes iommufd; no fixed version string is carried in this record, so track the commits into your own kernel build. Interim: do not expose /dev/iommu to untrusted tenants, keep the VMM as the only iommufd client, and prefer legacy VFIO type1 containers where the platform still supports it until the kernel is patched.

References