CVE-2026-89800: Linux Kernel Privilege Escalation Vulnerability

CVE-2026-89800 Overview

CVE-2026-89800 is a Linux kernel vulnerability in the Nouveau DRM driver's userspace virtual memory manager (uvmm). The flaw resides in the unwind path for OP_UNMAP_SPARSE operations within a bind job. When a successful sparse unmap is later followed by a failing operation in the same job, the unwind logic reverts the sparse unmap but fails to clear the reg->dirty flag. The region remains in uvmm->region_mt with its dirty state stuck and its completion never signalled. Subsequent binds targeting that virtual address range fail permanently for the lifetime of the uvmm.

Critical Impact
Local processes issuing GPU bind jobs against Nouveau can wedge a virtual address range, blocking all future binds with -ENOENT, -EINVAL, or an unkillable wait, producing a persistent denial of service against the GPU context.

Affected Products

Linux kernel — drm/nouveau/uvmm subsystem
Systems using the Nouveau open-source NVIDIA driver with GPU VM (GPUVM) bind jobs
Stable kernel branches referenced by upstream fix commits 1101cbf, 196ce9e5, 38a6230, a129b2b, and c60033c

Discovery Timeline

2026-09-16 - CVE-2026-89800 published to NVD
2026-09-16 - Last updated in NVD database

Technical Details for CVE-2026-89800

Vulnerability Analysis

The Nouveau uvmm code handles GPU virtual address bind jobs composed of multiple operations. A successful OP_UNMAP_SPARSE marks the affected region dirty via nouveau_uvma_region_dirty() and defers the actual teardown to nouveau_uvmm_bind_job_cleanup(). The region intentionally stays in the uvmm->region_mt maple tree until cleanup runs.

When a later operation in the same job fails, the driver walks the unwind path to revert prior operations. The unwind reverses the sparse unmap and sets op->reg = NULL, but never clears reg->dirty. Because op->reg is nulled, the cleanup path also skips the teardown. The region is left permanently in the tree with dirty set and its completion never signalled.

Root Cause

The root cause is asymmetric state handling in the unwind logic. The dirty flag is set in one location but cleared in none. Combined with the unwind clearing op->reg, this creates an orphaned tree entry the cleanup path cannot reach. This falls under improper state management in a kernel driver, specifically a resource-lifecycle bug in GPU virtual memory bookkeeping.

Attack Vector

A local user with access to a Nouveau-managed GPU device (typically via DRM render nodes) can craft a bind job containing a successful OP_UNMAP_SPARSE followed by an operation guaranteed to fail. Once the unwind executes, the targeted virtual address range in that uvmm becomes unusable. Any subsequent bind that intersects the range returns -ENOENT or -EINVAL from the dirty checks, or blocks in an unkillable wait_for_completion() inside bind_validate_region(). The condition persists for the lifetime of the uvmm context.

// No verified public exploit code available.
// See kernel commits referenced below for the corrected unwind logic
// that clears reg->dirty when reverting an OP_UNMAP_SPARSE.

Detection Methods for CVE-2026-89800

Indicators of Compromise

Repeated -ENOENT or -EINVAL returns from Nouveau uvmm bind ioctls against a specific virtual address range within a single process context.
Processes hung in wait_for_completion() inside bind_validate_region() in the Nouveau driver, visible in /proc/<pid>/stack.
Kernel log entries from the nouveau module referencing failed bind jobs preceded by sparse unmap operations.

Detection Strategies

Monitor kernel version and package inventory to identify hosts running vulnerable Nouveau code paths that predate the fix commits.
Alert on unusual patterns of failing GPU bind ioctls from unprivileged processes, particularly repeated failures against the same address range.
Correlate GPU driver errors in dmesg with process activity to identify local users triggering repeated bind-job failures.

Monitoring Recommendations

Track task state for processes blocked in Nouveau completion waits, since the vulnerability produces unkillable waiters that persist until reboot.
Ingest dmesg and journald GPU driver messages into a centralized log store for retrospective analysis.
Baseline expected DRM ioctl error rates per user and workload to surface anomalous bind-job failure spikes.

How to Mitigate CVE-2026-89800

Immediate Actions Required

Update to a Linux kernel build containing the upstream fix that clears reg->dirty during unwind of OP_UNMAP_SPARSE.
On systems that do not require the Nouveau driver, blacklist the nouveau module to remove the attack surface entirely.
Restrict access to DRM render nodes (/dev/dri/renderD*) to trusted users and groups only, since exploitation requires local GPU device access.

Patch Information

The fix is applied across multiple stable kernel branches. Reference the upstream commits: Kernel Update Commit 1101cbf, Kernel Update Commit 196ce9e5, Kernel Update Commit 38a6230, Kernel Update Commit a129b2b, and Kernel Update Commit c60033c. Rebuild or install a distribution kernel package that incorporates one of these commits.

Workarounds

Unload the nouveau module (modprobe -r nouveau) on systems that do not require it, and blacklist it in /etc/modprobe.d/ to prevent auto-loading.
Tighten permissions on /dev/dri/renderD* so only vetted users can submit GPU bind jobs to Nouveau.
Reboot affected hosts to clear wedged uvmm contexts, since the stuck state persists for the process lifetime until the vulnerable code path is patched.

bash

# Blacklist the nouveau driver until a patched kernel is deployed
echo "blacklist nouveau" | sudo tee /etc/modprobe.d/blacklist-nouveau.conf
sudo update-initramfs -u
sudo reboot