CVE-2026-89451

What it actually does

A race in the Linux kernel IOMMU Shared Virtual Addressing (SVA) bind path publishes an SVA attach handle into the group PASID lookup before handle->dev is set and before iommu_sva_lock is dropped. A concurrent bind can reuse that handle while the device pointer is still NULL. A later iommu_sva_unbind_device() then NULL-dereferences handle->dev->iommu_group, causing a kernel oops or panic. Impact is primarily host availability (crash), not confidentiality or a clean remote code-execution primitive.

Why it matters to the business

Linux hosts that use IOMMU SVA/PASID (accelerators, GPUs, NICs, or other devices sharing process address space) can crash and reboot if bind and unbind race, interrupting production workloads and multi-tenant guests. The flaw is not in CISA KEV, is not associated with ransomware, and has no reported in-the-wild use about 30 days after publication, so urgency is driven by local DoS risk on SVA-enabled kernels rather than mass exploitation. Unpatched kernel crashes still mean unplanned downtime, dump collection, and recovery cost wherever SVA is in use.

How an attack unfolds

A local actor who can trigger IOMMU SVA bind and unbind (via drivers or interfaces that call iommu_sva_bind_device / iommu_sva_unbind_device on a vulnerable kernel) overlaps two bind operations. The first install makes the handle visible in the group PASID table before handle->dev is initialized; after the lock is released, the second bind reuses that handle and returns it with a NULL device pointer. Unbind then walks handle->dev->iommu_group and the kernel faults. There is no described unauthenticated network path; success depends on concurrent SVA activity, IOMMU SVA support, and the pre-fix initialization order. No named threat actors or public exploit tooling are associated with this issue.

How to fix it

Install a Linux kernel that contains the iommu/sva fix initializing handle->dev before the SVA handle is published and before iommu_sva_lock is released, then reboot onto that kernel. Use your distribution’s patched kernel package once the advisory is available; this record does not list exact fixed versions. There is no complete userspace workaround because the race is lock-ordering in the kernel. Until patched, limit untrusted local workloads from SVA/PASID bind interfaces and from managing IOMMU-backed devices, and avoid exposing those bind paths in multi-tenant designs.

How to confirm the fix worked

Confirm the running kernel changelog or package advisory includes the iommu/sva change that sets handle->dev before the handle is visible. On source-based builds, verify iommu_sva_bind_device / iommu_attach_device_pasid initializes handle->dev while iommu_sva_lock is still held. After upgrade, reboot and verify uname -r matches the patched package. Exposure is limited to kernels that implement IOMMU SVA and actually bind PASIDs; hosts without SVA/PASID usage are not practically affected even if the vulnerable code is present.

Typical attack path

1. Gain local ability to exercise IOMMU SVA bind/unbind on a Linux host with SVA/PASID-capable devices
2. Overlap concurrent bind operations so a handle is visible in the group PASID lookup before handle->dev is initialized
3. Obtain or reuse the incompletely initialized SVA handle after iommu_sva_lock is dropped
4. Invoke unbind on that handle so the kernel dereferences a NULL handle->dev
5. Cause a kernel oops/panic and host outage (denial of service)

How to detect it

Prior exploitation is unlikely (exploit maturity none, not KEV, no attributed actors), but a successful race leaves kernel fault evidence, not a stable implant. Search dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, kdump/vmcore, and panic/oops collectors for NULL pointer dereference with iommu_sva_unbind_device or other iommu/sva frames on the call trace around concurrent bind/unbind. Correlate with processes or drivers that bind PASID/SVA devices shortly before the crash. Absence of those oops signatures does not prove the race was never attempted; it only shows it did not take the crashing unbind path.

• iommu_sva_unbind_device
• iommu_sva_bind_device
• iommu_attach_device_pasid
• Unable to handle kernel NULL pointer dereference
• kernel NULL pointer dereference
• Call Trace:
• iommu_group

What your security team should do

• Patch and reboot Linux hosts that enable IOMMU SVA/PASID first (accelerators, GPU/NIC shared address space, device passthrough)
• Inventory where SVA bind/unbind is reachable and restrict untrusted local access to those interfaces until patched
• Treat this as a kernel availability bug with standard (non-KEV) SLAs unless the host is multi-tenant or safety-critical
• Watch vendor kernel advisories for exact package versions; none were supplied with this record
• Hunt historical kernel oops/panic logs for iommu_sva unbind NULL-pointer traces rather than assuming compromise