HIGH Introduced in 6.6
nouveau UnmapSparse UAF
CVE-2026-89801
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
KernelScan AI7.0HIGH
01Description
In the Linux kernel, the following vulnerability has been resolved: drm/nouveau/uvmm: fix premature region free on failed OP_UNMAP_SPARSE In nouveau_uvmm_bind_job_submit()'s OP_UNMAP_SPARSE arm, op->reg is set from nouveau_uvma_region_find(), which only looks the region up and takes no reference; a region's sole reference is its membership in uvmm->region_mt. Two failure paths leave op->reg set: the -ENOENT check when the region is busy, and the drm_gpuvm_sm_unmap_ops_create() failure. The sibling nouveau_uvmm_sm_unmap_prepare() failure just below clears op->reg; these two do not. unwind_continue steps back one op, so the failing op is skipped by the unwind loop and its op->reg stays set. nouveau_uvmm_bind_job_cleanup() then enters its if (op->reg) branch and calls nouveau_uvma_region_remove() and nouveau_uvma_region_put() 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 drm_gpuvm_sm_unmap_ops_create() 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.
02KernelScan AI Analysis
Risk summary
A local user with access to a nouveau GPU device node can trigger a use-after-free in the GPU virtual memory manager. When a VM bind operation fails on certain error paths, a VM region belonging to another job is prematurely freed, leading to memory corruption exploitable for privilege escalation or denial of service. This requires an NVIDIA GPU running the nouveau driver and benefits from concurrent GPU VM operations to achieve the use-after-free.
Vulnerability analysis
In the nouveau GPU driver's virtual memory manager, an unmap operation looks up an existing memory region but fails to clear the reference when the operation fails. On certain error paths, cleanup logic then removes and frees that region even though the failing operation never created it. This frees live memory belonging to another concurrent GPU job, which later accesses the freed region. The fix ensures the region reference is cleared on both failure paths so cleanup cannot touch memory the operation did not create. The bug is reachable by any local process with access to the nouveau DRM device, typically through GPU virtual memory bind operations on a render node; triggering the actual use-after-free requires concurrent operations on the same memory region, with the initial premature free typically induced by memory pressure.
Lifecycle
03Fix Versions
| Branch | Introduced | Fixed in | Patch commit |
|---|---|---|---|
| 6.12 | 6.6 | 6.12.110 | 88114e3a9658 |
| 6.18 | 6.6 | 6.18.51 | 24c25b182d17 |
| 6.6 | 6.6 | 6.6.157 | ba42d8a1c2c7 |
| 7.2 | 6.6 | 7.2.5 | 4083d24c2636 |
| mainline | 6.6 | 7.3 | ccf930812f23 |
| cip/6.12 | 6.6 | 6.12.111-cip32 | 88114e3a9658 |
04CIP Kernels
State of the newest release of each Civil Infrastructure Platform SLTS tree, from CIP's own fix records.
| CIP tree | State |
|---|---|
| cip/6.12 | Fixed in 6.12.111-cip32 |