CVE-2026-89445: iommufd: Fix UAF in selftest IOPF reporting
In the Linux kernel, the following vulnerability has been resolved:
iommufd: Fix UAF in selftest IOPF reporting
IOMMUFD selftest TRIGGERIOPF borrows an attach handle from group->pasidarray without synchronizing against PASID detach, then a concurrent iommureportdevicefault() can dereference that borrowed handle's domain pointer after the detach erases the handle and frees the backing struct iommufdattachhandle. TRIGGERIOPF then dereferences the freed handle, causing a UAF.
Fix by adding a iopfrwsem in mockdev to follow the expected design of a real driver. Hold its read side across the whole iommureportdevicefault() call, and its write side around every path that attaches, detaches, or replaces a device domain. This can block new reports and drains in-flight reports before an old attach handle or the IOPF fault parameter can be removed. Also take the write side while registering a mock device, since it can invoke the mock driver's default-domain attach callback.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
The affected code is in the IOMMUFD selftest path, specifically mock-device IOPF reporting using TRIGGER_IOPF. The provided information does not identify exposure outside that selftest functionality.
What conditions are required to trigger the use-after-free?
A TRIGGER_IOPF operation must borrow an attach handle while a PASID detach occurs concurrently. A concurrent iommu_report_device_fault() can then use the handle's domain pointer after the detach has removed and freed the underlying attach-handle structure.
How does the fix prevent the race?
It adds an iopf_rwsem to the mock device. Fault reporting holds a read lock for the full iommu_report_device_fault() call, while attach, detach, device-domain replacement, and mock-device registration take the write lock so in-flight reports drain before old handles or fault parameters are removed.