Linux kernel (drivers/iommu/intel): The VT-d I/O page-fault reporting path looks up the faulting device with no

CVSS 8.8CVE-2024-35843Kernel, userspace & hypervisorcurated

Impact

The VT-d I/O page-fault reporting path looks up the faulting device with no synchronisation against the IOMMU release path, so a device can report a fault against a struct that is being freed underneath it. Use-after-free in host kernel context, with the timing of one side driven by a device a tenant controls and the other by a device release the tenant triggers when it tears down its VM.

Who can reach it

A tenant with an ATS/PRI-capable assigned device keeps the device emitting I/O page faults while releasing it - stopping the VM, unbinding, or letting the control plane reclaim the GPU/NIC. The fault report races the IOMMU's device-release path and lands on freed fault parameters. Requires Intel VT-d with PRI enabled on the assigned device; no host root. Note this is a teardown-window race, so it needs the tenant to control both the fault stream and the release, which a normal VM stop provides.

What to do

No fixed release is listed in this record; apply the linked stable commits or run a current stable/LTS kernel. Interim: disable PRI on tenant-assigned devices, and quiesce the device (stop the guest driver, disable ATS) before unbinding it during reclaim rather than pulling it while faults are in flight.

References

https://git.kernel.org/stable/c/3d39238991e745c5df85785604f037f35d9d1b15 https://git.kernel.org/stable/c/def054b01a867822254e1dda13d587f5c7a99e2a https://nvd.nist.gov/vuln/detail/CVE-2024-35843

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.