CVE-2026-89800 in Linux
Summary
by MITRE • 09/16/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau/uvmm: clear the dirty flag when unwinding an OP_UNMAP_SPARSE
A successful OP_UNMAP_SPARSE marks its region dirty with nouveau_uvma_region_dirty() and defers the teardown to nouveau_uvmm_bind_job_cleanup(); it does not remove the region from uvmm->region_mt.
If a later op in the job fails, the unwind path never clears reg->dirty (set in one place, cleared nowhere) and sets op->reg = NULL, so cleanup skips the teardown. The region is left in the tree with dirty set and its completion never signalled. Later binds over that range then fail permanently -- -ENOENT or -EINVAL from the dirty checks, or an unkillable wait_for_completion() in bind_validate_region() -- for the lifetime of the uvmm.
Clear reg->dirty when the unwind reverts the sparse unmap, restoring the region to the state it was found in.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/16/2026
The vulnerability resides within the Nouveau driver's Unified Virtual Memory Management subsystem in the Linux kernel, specifically affecting the handling of sparse memory unmapping operations. The core technical flaw is a logic error during the unwinding phase of an operation sequence when a subsequent command fails. When an OP_UNMAP_SPARSE operation executes successfully, it marks its associated region as dirty using nouveau_uvma_region_dirty and defers the actual teardown to a cleanup job. Crucially, this process does not immediately remove the memory region from the uvmm->region_mt management tree. This design is intended for normal completion paths but creates a critical state inconsistency when error handling is triggered later in the same operation sequence.
If a subsequent operation within the same job fails and triggers an unwind path to revert previous changes, the code correctly attempts to restore the state of prior operations. However, it fails to clear the reg->dirty flag that was set by the successful OP_UNMAP_SPARSE. Furthermore, the unwind logic sets op->reg to NULL, which causes the cleanup routine to skip the necessary teardown steps for that region. As a result, the memory region remains registered in the management tree with its dirty bit still asserted, and its completion event is never signaled. This leaves the subsystem in an inconsistent state where it believes the operation completed successfully despite being rolled back logically.
The operational impact of this flaw is severe and persistent for the lifetime of the uvmm instance. Because the region remains marked as dirty but lacks proper cleanup signaling, any subsequent bind operations targeting that memory range will fail permanently. These failures manifest as -ENOENT or -EINVAL errors returned from dirty checks within the validation logic, or they can cause processes to hang indefinitely due to an unkillable wait_for_completion call in bind_validate_region. This effectively results in a denial of service for GPU memory allocation and mapping functions related to that specific range, potentially requiring a system reboot or driver reload to restore functionality.
From a classification perspective, this vulnerability aligns with CWE-459, which covers Incomplete Cleanup, as the system fails to properly revert state changes during error handling. It also relates to CWE-832, involving Unlock of a resource that is not locked, in the sense that synchronization primitives are left in an inconsistent state leading to deadlocks or hangs. Within the MITRE ATT&CK framework, this could be leveraged for Denial of Service against graphics processing units and associated applications, potentially falling under T1499 if used to exhaust system resources through hung processes, though it is primarily a stability issue rather than a direct security exploit vector in most contexts.
Mitigation strategies involve applying the upstream kernel patch that explicitly clears reg->dirty when unwinding an OP_UNMAP_SPARSE operation. This ensures that the region's state is fully restored to its pre-operation condition during error handling paths. System administrators should ensure their Linux kernels are updated with this fix, particularly for systems relying on NVIDIA GPUs via the Nouveau open-source driver. For environments where stability is critical, monitoring GPU memory allocation logs for persistent -ENOENT or -EINVAL errors can help identify affected instances before they lead to application hangs.