Linux kernel (drivers/iommu): With iommufd, a tenant can change a passthrough device's IOMMU domain while MSI

Impact

With iommufd, a tenant can change a passthrough device's IOMMU domain while MSI interrupts are being programmed, and the MSI descriptor still held a raw pointer into the old domain's cookie. Racing the two ioctls gives a use-after-free on the structure that decides where the device's interrupt writes land - kernel memory corruption reached from a VM's own device fd, and an interrupt address the attacker has influence over.

Who can reach it

A tenant VMM holding /dev/vfio/* plus /dev/iommu races VFIO_DEVICE_ATTACH_IOMMUFD_PT (which re-attaches the IOMMU domain) against VFIO_DEVICE_SET_IRQS (which composes the translated MSI message) on the same device. Both are ordinary unprivileged ioctls on fds a passthrough tenant already owns; the fix notes the unlocked iommu_get_domain_for_dev() on the MSI translation path is a second UAF in the same window. Requires the iommufd path (not legacy VFIO type1 containers, which could not swap domains at runtime).

What to do

No fixed release is listed in this record; apply the linked stable commits or run a current stable/LTS kernel on every passthrough node. Interim: keep tenants on the legacy VFIO type1 container path rather than iommufd where the platform still allows it, since type1 cannot change the domain while the device is live, and do not expose /dev/iommu to untrusted containers.

References