CVE-2026-89446

What it actually does

A Linux kernel iommufd error path leaks the current IOAS object reference and leaves the iova_rwsem write lock held when xa_store() fails. Unwind logic only drops IOAS entries already inserted into the temporary xarray, so the in-flight IOAS is never unlocked or put. The stuck write lock can stall later IOAS/IOVA operations indefinitely and the leaked reference can block teardown, producing a local denial-of-service in the userspace IOMMU interface.

Why it matters to the business

Availability risk is concentrated on hosts that use iommufd for VFIO, device passthrough, nested virtualization, or other userspace IOMMU management: hung mapping operations can freeze VMs, passthrough devices, or DMA setup until reboot. The issue is not in CISA KEV, is not associated with ransomware, has no reported in-the-wild use, and EPSS is about 0.002 with no movement over 30 days, so urgency is low-to-moderate and should follow normal kernel patching unless untrusted tenants can reach iommufd.

How an attack unfolds

A local caller who can use iommufd drives the take-all-iova-rwsem path so the kernel takes an IOAS reference and the iova_rwsem write lock, then forces xa_store() to fail before that IOAS is inserted into the temporary xarray. Cleanup only walks entries already in the xarray, so the current lock and reference are left behind. Later IOMMU mapping or IOAS management then blocks on the held write lock, denying service to passthrough and virtualization workloads. Exploitation requires local access to the iommufd interface and a way to fail the store (typically resource pressure); there are no known campaigns, named threat actors, or public exploit maturity.

How to fix it

Install a vendor or upstream Linux kernel that includes the iommufd fix to drop the current IOAS rwsem and object reference before unwinding previously stored xarray entries on xa_store() failure. Exact package versions were not listed with this advisory; use your distribution’s kernel security update that references this change (commit message: iommufd: Release current IOAS on xa_store() failure). Until patched, limit who can open the iommufd device, do not expose it to untrusted containers or guests, and avoid untrusted workloads that can stress IOAS management. Rebuild from the corresponding stable-tree patch only if a distro package is not yet available.

How to confirm the fix worked

Confirm the running kernel changelog or package notes include the iommufd xa_store failure-path fix. Inventory whether the iommufd character device is present and which processes hold it. After patching, verify IOAS create/replace/destroy and mapping updates complete under load without tasks remaining blocked on iova_rwsem. On still-unpatched hosts, treat open iommufd users in virtualization and passthrough stacks as exposed.

Typical attack path

1. Gain local access on a Linux system where iommufd is exposed and the caller can create and manage IOAS objects.
2. Exercise the iommufd path that takes all IOVA rwsems and stores IOAS objects into a temporary xarray.
3. Cause xa_store() to fail after the current IOAS is locked and referenced but before it is inserted into that xarray.
4. Leave the unreaped write lock and object reference in place so subsequent IOAS/IOVA operations block.
5. Rely on hung passthrough, VM, or DMA-mapping work to achieve denial of service; repeat if needed after reboot.

How to detect it

There is no known in-the-wild exploitation, no named actors, and no network payload. Hunt for availability artifacts after iommufd use: kernel hung-task reports, processes in uninterruptible sleep during IOAS or IOVA updates, and virtualization/passthrough threads that never complete mapping changes. Review kernel logs around iommufd activity and correlate with local users or containers that can open the iommufd device. A single hang after resource pressure is more consistent with this bug than with malware; reboot clears the leaked lock but does not prove compromise.

What your security team should do

• Patch kernels first on VFIO, device-passthrough, and nested-IOMMU hosts; use standard cadence elsewhere given low EPSS, flat 30-day trend, no KEV listing, and no ransomware use.
• Until updated, restrict iommufd to trusted virtualization and admin components and keep it out of untrusted containers and guests.
• Watch for hung tasks and prolonged IOAS/IOMMU mapping stalls as a temporary availability signal.
• Track distro kernel advisories for the exact fixed package; no CISA due date applies.
• Do not treat this as an emergency remote-compromise event; it is a local error-path lock and reference leak.