CVE-2026-89451: iommu/sva: Set handle->dev before the SVA handle is visible
In the Linux kernel, the following vulnerability has been resolved:
iommu/sva: Set handle->dev before the SVA handle is visible
iommuattachdevicepasid() installs the new SVA attach handle in the group PASID lookup before iommusvabinddevice() returns. A concurrent bind can therefore find and reuse the same handle after iommusvalock is dropped.
handle->dev was initialized after dropping iommusvalock. This leaves a window where a racing bind can return a handle whose dev pointer is still NULL. A subsequent iommusvaunbinddevice() can then dereference it via handle->dev->iommugroup.
Initialize handle->dev before releasing iommusvalock so any visible SVA handle is fully initialized.
Affected Software
Event History
Frequently Asked Questions
What conditions are required to trigger the issue?
The issue requires concurrent SVA device-bind activity: one bind makes an SVA handle visible while another racing bind finds and reuses it before its dev pointer has been initialized. A later unbind of that handle can dereference the NULL dev pointer.
What is the practical impact of a successful race?
A subsequent iommu_sva_unbind_device() can dereference handle->dev through handle->dev->iommu_group while handle->dev is NULL. The provided data identifies this as a kernel vulnerability but does not specify further impact such as privilege escalation or information disclosure.
What change mitigates the race when applying the fix?
Initialize handle->dev before releasing iommu_sva_lock, ensuring that every SVA handle visible through the group PASID lookup is fully initialized. The listed stable kernel references contain the corresponding fixes.