Linux kernel iommu/sva: racing bind can return an SVA handle with a NULL dev pointer

UnscoredCVE-2026-89451Kernel, userspace & hypervisorcurated

Impact

IOMMU SVA is what lets an accelerator walk a process's page tables directly, so it is live on nodes running AMD IOMMU PPR-capable GPUs or any PASID-capable device. iommu_attach_device_pasid() publishes the attach handle into the group PASID lookup before iommu_sva_bind_device() finishes filling it in, and handle->dev was only set after iommu_sva_lock was dropped. A second thread binding the same device concurrently can pick up that handle while handle->dev is still NULL, and a later iommu_sva_unbind_device() dereferences it as handle->dev->iommu_group. The result is a NULL-pointer dereference in kernel context - a node panic, which on a GPU node means an unplanned loss of every tenant on that host, not a contained crash. Reaching it requires local ability to open an SVA-capable accelerator device and win a narrow race.

Who can reach it

Local user with access to a device node that can bind SVA/PASID (an accelerator character device). No remote path, no network exposure. Needs two concurrent bind calls against the same device to hit the window.

What to do

Take the stable kernel containing the fix (four stable commits linked) and reboot each affected node. There is no runtime mitigation short of denying tenants access to SVA-capable device nodes. Plan it as a rolling drain-and-reboot across the fleet; the advisory names no fixed release number, only the stable commits.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-89451 https://git.kernel.org/stable/c/37a96a30617a4c96f048a5874c00509bc4fe4d85 https://git.kernel.org/stable/c/bcffb1c75da8fc9d51168ff9f09d471c26507912

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.