CVE-2026-89800: drm/nouveau/uvmm: clear the dirty flag when unwinding an OP_UNMAP_SPARSE
In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau/uvmm: clear the dirty flag when unwinding an OPUNMAPSPARSE
A successful OPUNMAPSPARSE marks its region dirty with nouveauuvmaregiondirty() and defers the teardown to nouveauuvmmbindjobcleanup(); it does not remove the region from uvmm->regionmt.
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 waitforcompletion() in bindvalidateregion() -- 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Apply the fix in drm/nouveau/uvmm to clear reg->dirty when the unwind path reverts an OP_UNMAP_SPARSE, so that if a later op fails and the unwind occurs, the unwind path clears reg->dirty, preventing the region from being left in the tree with dirty set and avoiding completion never being signalled.
Linux kernel (drm/nouveau/uvmm) nouveau_uvma_region_dirty flag handling = clear the dirty flag when unwinding an OP_UNMAP_SPARSE
Event History
Frequently Asked Questions
What conditions are needed to trigger the persistent failure?
A successful OP_UNMAP_SPARSE must be followed by a later operation in the same job that fails. During unwind, the sparse-unmapped region can remain marked dirty without teardown or completion signalling.
What is the operational impact after the failure occurs?
Later binds over the affected range can fail permanently with -ENOENT or -EINVAL due to dirty-region checks. They can also block indefinitely in wait_for_completion() in bind_validate_region(), and the condition persists for the lifetime of the uvmm.
Is restarting the affected uvmm necessary to recover?
The description states that the broken region state persists for the lifetime of the uvmm. No other recovery method is provided in the available data.