CVE-2026-89801: drm/nouveau/uvmm: fix premature region free on failed OP_UNMAP_SPARSE
In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau/uvmm: fix premature region free on failed OPUNMAPSPARSE
In nouveauuvmmbindjobsubmit()'s OPUNMAPSPARSE arm, op->reg is set from nouveauuvmaregionfind(), which only looks the region up and takes no reference; a region's sole reference is its membership in uvmm->regionmt. Two failure paths leave op->reg set: the -ENOENT check when the region is busy, and the drmgpuvmsmunmapopscreate() failure. The sibling nouveauuvmmsmunmapprepare() failure just below clears op->reg; these two do not.
unwindcontinue steps back one op, so the failing op is skipped by the unwind loop and its op->reg stays set. nouveauuvmmbindjobcleanup() then enters its if (op->reg) branch and calls nouveauuvmaregionremove() and nouveauuvmaregionput() on it, dropping the tree's sole reference and freeing a region this job never created. The comment above the cleanup loop documents the broken invariant: op->reg must be NULL on submit failure.
This frees a live region on an unrelated failure, reachable single-job when drmgpuvmsmunmapopscreate() returns -ENOMEM; if another job owns the same region, its cleanup then removes and puts the freed region, a use-after-free. Clear op->reg on both failure paths.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Operational
Fix the cleanup/invariant so op->reg is cleared on both OP_UNMAP_SPARSE failure paths in nouveau_uvmm_bind_job_submit(): ensure op->reg is set to NULL (or otherwise cleared) after the -ENOENT check and after the failure handling that would free/put a region the job never created, so the unwind/cleanup loop does not call nouveau_uvma_region_remove()/nouveau_uvma_region_put() on an already-freed region.
Event History
Frequently Asked Questions
What conditions are required to trigger the faulty cleanup?
A failed OP_UNMAP_SPARSE submission must leave a region pointer set. The described paths are a busy-region -ENOENT result and failure of drm_gpuvm_sm_unmap_ops_create(); the latter is reachable by a single job when it returns -ENOMEM.
What is the impact of the failed operation?
Cleanup can remove and release a live UVMM region that the failed job did not create. Because the region's only reference is its membership in the region tree, this can free the region while another job may still own or use it, resulting in a use-after-free.
Can affected systems be identified by kernel version from this information?
No affected or fixed kernel version ranges are provided. The supplied stable-kernel references should be used to determine whether the relevant fixes are present in a specific kernel tree.