CVE-2026-89447 in Linux
Summary
by MITRE • 09/12/2026
In the Linux kernel, the following vulnerability has been resolved:
iommufd: Avoid locking internal accesses during unmap
iommufd_access_notify_unmap() skips internal accesses because they do not have an external unmap callback to invoke.
However, the current test calls iommufd_lock_obj() before checking whether the access is internal. If iommufd_lock_obj() succeeds, the loop then sees the internal access and continues, bypassing the matching iommufd_put_object() used by the normal unmap path. This leaks the object reference taken by iommufd_lock_obj().
Check for internal accesses first so skipped entries are never locked.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/12/2026
The vulnerability identified in the Linux kernel's IOMMU file descriptor subsystem, specifically within the iommufd_access_notify_unmap function, represents a classic race condition and resource management error rooted in incorrect locking semantics. The core issue arises from the sequence of operations performed when an unmap notification is processed for DMA access contexts. In this specific code path, the system iterates through various accesses associated with an IOMMU domain to handle cleanup or state changes during unmapping operations. A critical distinction exists between internal accesses and external ones; internal accesses are managed entirely within the kernel's virtualization infrastructure and do not require invocation of external unmap callbacks that might be registered by user-space drivers or other subsystems. Consequently, these internal entries should logically be skipped to avoid unnecessary processing overhead and potential side effects associated with external interfaces.
However, the flawed implementation performs a locking operation via iommufd_lock_obj before determining whether an access is internal. This function call increments reference counts on objects to ensure they remain valid during inspection or modification. When the loop encounters an internal access after this lock has been acquired, it correctly identifies that no external callback needs to be invoked and proceeds to skip further processing for that specific entry. The critical failure lies in what happens next: because the object was locked earlier, standard cleanup routines such as iommufd_put_object are bypassed or not executed with equal frequency compared to non-internal paths. This results in a reference count leak where the kernel retains ownership of an object without releasing it back into the general pool when that access is no longer needed. Over time, particularly under high-frequency unmapping scenarios common in virtualized environments using SR-IOV or nested IOMMU configurations, these leaked references accumulate.
The operational impact of this reference count leak manifests primarily as a gradual degradation of system stability and potential denial-of-service conditions. As kernel objects retain stale references indefinitely, memory consumption increases monotonically without corresponding utility. Eventually, the exhaustion of available object handles can lead to allocation failures for new IOMMU contexts or DMA mappings. This effectively prevents devices from being assigned to virtual machines or applications that require direct hardware access, disrupting critical workloads in cloud computing and enterprise server environments. Furthermore, while less immediate than memory leaks, improper locking sequences often introduce subtle concurrency hazards where the state of locked objects might be inspected inconsistently relative to other threads modifying those same structures, potentially leading to undefined behavior if additional checks were added later without accounting for this asymmetry.
From a classification perspective, this vulnerability aligns with CWE-401, which describes missing release of memory after successful allocation, and more specifically relates to improper resource management during error handling or conditional execution paths. In the context of the MITRE ATT&CK framework, while not an exploit technique per se, it reflects weaknesses in system resource monitoring and lifecycle management that could be leveraged by attackers aiming for availability impact through resource exhaustion attacks. The root cause is a logical ordering defect where protective locking mechanisms are applied indiscriminately without considering whether subsequent cleanup steps will actually execute for all code paths.
The resolution involves reordering the conditional checks within iommufd_access_notify_unmap to evaluate whether an access is internal before attempting any locks or modifications. By checking this property first, the kernel can bypass locked entries entirely, ensuring that no reference counts are incremented unnecessarily and that subsequent cleanup routines remain consistent across all execution paths. This fix ensures symmetry in resource acquisition and release, adhering to best practices for lock ordering and scope minimization. Administrators should apply vendor-provided patches or update their Linux kernels to versions where this logic has been corrected to prevent long-term stability issues associated with unbounded memory growth in IOMMU management structures.