CVE-2026-89447

What it actually does

A reference-count leak in the Linux kernel iommufd unmap path. iommufd_access_notify_unmap() called iommufd_lock_obj() before testing whether an access was internal. Internal accesses have no external unmap callback and are skipped, so the matching iommufd_put_object() never ran. Each such unmap permanently holds a kernel object reference. Repeated hits can exhaust iommufd object references and associated kernel memory, producing a local denial of service rather than memory corruption or privilege escalation.

Why it matters to the business

Operational risk is limited and primarily local. EPSS is about 0.0022 and has been flat for 30 days, the issue is not in CISA KEV, ransomware use is not reported, and exploit maturity is none more than a month after publication. Impact is concentrated on hosts that expose iommufd for userspace IOMMU management, VFIO, or device assignment: leaked objects can eventually block new mappings, break passthrough, or force a reboot. Most general-purpose servers and desktops that do not use this interface see little practical exposure. Treat as a standard kernel hygiene patch, not an emergency campaign-driven event.

How an attack unfolds

There is no known in-the-wild use and no named threat actors associated with this flaw. A local process that can open the iommufd interface and drive map/unmap of IOMMU accesses could, before the fix, cause the kernel to take a lock/reference on an internal access object and then skip the corresponding put. Repeating that unmap pattern leaks references until iommufd or related kernel allocations fail, denying IOMMU services or destabilizing the host. The path is local-only, requires ability to exercise iommufd unmap with internal accesses, and does not by itself yield code execution or data theft.

How to fix it

Install a Linux kernel update that includes the iommufd fix: test for internal accesses before calling iommufd_lock_obj() in iommufd_access_notify_unmap() so skipped entries are never locked and no reference is leaked. Use your distribution or vendor kernel package once it advertises CVE-2026-89447 or the corresponding stable-tree iommufd unmap change; rebuild custom kernels from a tree that contains that commit. No complete configuration workaround is documented. Until patched, restrict who can open the iommufd device node, limit untrusted workloads that perform VFIO/IOMMU userspace management, and avoid exposing iommufd to untrusted tenants or containers.

How to confirm the fix worked

Confirm the running kernel changelog or stable commit list includes the iommufd change that checks internal accesses before iommufd_lock_obj() in the unmap notify path. On patched trees, inspect iommufd_access_notify_unmap() and verify internal accesses are filtered before any lock/get. Inventory hosts that load iommufd and have /dev/iommu (or equivalent) present; those are the in-scope systems. After upgrade, reboot into the new kernel, verify uname and package version, and regression-test legitimate VFIO/IOMMU unmap flows. Watch kernel object and slab usage for iommufd-related caches during unmap soak tests to ensure reference counts return to baseline.

Typical attack path

1. Obtain local code execution or an account that can use the iommufd userspace interface (typically /dev/iommu) on an unpatched Linux kernel.
2. Create IOMMU address-space and access objects, including internal accesses that the unmap notifier is supposed to skip.
3. Trigger unmap/notify-unmap operations so the kernel locks an internal access object and then continues without dropping the reference.
4. Repeat until leaked object references or kernel memory associated with iommufd are exhausted.
5. Cause allocation or unmap failures that deny device assignment/IOMMU operations or force a host reboot (denial of service).

How to detect it

This is a silent kernel reference leak, not a network implant, so there are no reliable post-exploitation file or C2 artifacts. Hunt for prior abuse only on hosts that used iommufd. Review audit/syscall logs for untrusted processes opening /dev/iommu and issuing high-rate IOMMU map/unmap ioctls before the patch window. Compare historical kmem/slab or kmemleak output for steadily growing iommufd-related objects that never drop after unmap. Check dmesg/journal for IOMMU/iommufd warnings, allocation failures, or hung unmap around the same time. Persistent leak typically looks like unexplained growth in iommufd object counts or inability to create new IOMMU contexts until reboot—not a distinct malware signature. No named APT or ransomware campaign is tied to this CVE.

• /dev/iommu
• iommufd
• iommufd_access_notify_unmap
• iommufd_lock_obj

What your security team should do

• Patch and reboot Linux hosts that use iommufd/VFIO/userspace IOMMU as a normal kernel update; this is not a KEV or active-exploitation emergency.
• Prioritize hypervisors, nested-virtualization, and device-passthrough nodes over general-purpose systems that never open iommufd.
• Until patched, tighten permissions on the iommufd device node and keep untrusted tenants from driving IOMMU unmap.
• Track distro kernel advisories for the exact package that ships this fix; affected and fixed version lists were not supplied with this record.
• Do not invest in exploit-specific detections beyond generic local iommufd abuse and resource-exhaustion monitoring given EPSS ~0.0022, no KEV listing, and exploit maturity none.