CVE-2026-89801: Linux Kernel Use-After-Free Vulnerability

CVE-2026-89801 Overview

CVE-2026-89801 is a use-after-free vulnerability in the Linux kernel's Nouveau DRM (Direct Rendering Manager) driver, specifically within the userspace virtual memory manager (uvmm) subsystem. The flaw resides in nouveau_uvmm_bind_job_submit() where the OP_UNMAP_SPARSE handling fails to clear op->reg on two error paths. When cleanup runs, the code frees a region the job never owned, dropping the tree's only reference. A second job holding the same region then dereferences freed memory, producing a use-after-free condition on GPU virtual memory management structures.

Critical Impact
A local, authenticated user with access to the Nouveau GPU driver can trigger a use-after-free that may lead to kernel memory corruption, privilege escalation, or denial of service.

Affected Products

Linux kernel versions containing the drm/nouveau/uvmm subsystem prior to the fix commits
Distributions shipping vulnerable Nouveau DRM drivers on systems with NVIDIA GPUs
Stable kernel branches referenced by patch commits 24c25b18, 4083d24c, 88114e3a, ba42d8a1, and ccf93081

Discovery Timeline

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

Technical Details for CVE-2026-89801

Vulnerability Analysis

The vulnerability exists in the OP_UNMAP_SPARSE branch of nouveau_uvmm_bind_job_submit(). The function calls nouveau_uvma_region_find() to locate a region, which returns a pointer without taking a reference. The region's sole reference is its membership in uvmm->region_mt.

Two failure paths leave op->reg set to the located region: the -ENOENT check when the region is busy, and the failure return from drm_gpuvm_sm_unmap_ops_create(). The adjacent nouveau_uvmm_sm_unmap_prepare() failure path correctly clears op->reg, but these two paths do not.

The unwind_continue label steps back one operation, causing the unwind loop to skip the failing op. When nouveau_uvmm_bind_job_cleanup() executes, it enters the if (op->reg) branch and calls nouveau_uvma_region_remove() followed by nouveau_uvma_region_put(). This drops the tree's sole reference and frees a region the job never created.

Root Cause

The root cause is a broken invariant documented in the cleanup loop's comment: op->reg must be NULL on submit failure. The two failure paths violate this invariant by leaving a non-owning pointer set. The cleanup logic cannot distinguish between regions the job created and regions it merely looked up, treating both as owned resources requiring release [CWE-416].

Attack Vector

Exploitation requires local access with the ability to issue DRM ioctls to the Nouveau driver. An attacker submits a bind job whose OP_UNMAP_SPARSE operation triggers one of the two failing conditions, such as forcing drm_gpuvm_sm_unmap_ops_create() to return -ENOMEM through memory pressure. If another concurrent or subsequent job references the same region in uvmm->region_mt, its cleanup path operates on freed memory. This produces a use-after-free that an attacker can shape into kernel memory corruption or privilege escalation. Detailed patch mechanics are available in the referenced Kernel Git Commit 24c25b182.

Detection Methods for CVE-2026-89801

Indicators of Compromise

Kernel oops or panic messages referencing nouveau_uvma_region_put, nouveau_uvma_region_remove, or nouveau_uvmm_bind_job_cleanup in dmesg output
KASAN (Kernel Address Sanitizer) reports flagging use-after-free within the Nouveau uvmm subsystem
Unexpected GPU process crashes or DRM ioctl failures returning -ENOMEM under memory pressure

Detection Strategies

Enable KASAN on test kernels to catch the use-after-free at the point of the second access
Monitor kernel logs for stack traces originating in drm/nouveau/nouveau_uvmm.c cleanup paths
Audit installed kernel package versions against the fixed stable releases listed in the kernel.org commits

Monitoring Recommendations

Collect and centralize /var/log/kern.log and journalctl -k output across Linux fleets for pattern matching on Nouveau symbols
Track kernel version inventory and flag hosts running Nouveau on unpatched builds
Alert on repeated segmentation faults or GPU resets on workstations using NVIDIA hardware with the open-source driver

How to Mitigate CVE-2026-89801

Immediate Actions Required

Apply the upstream kernel patches referenced in the stable tree commits and rebuild or update affected kernels
Inventory systems running Nouveau on NVIDIA GPUs and prioritize multi-user or shared workstations for patching
Restrict access to DRM devices (/dev/dri/*) so only trusted local users can submit GPU bind jobs

Patch Information

The fix clears op->reg on both previously-broken failure paths in nouveau_uvmm_bind_job_submit(), restoring the invariant expected by the cleanup loop. Patches are available in the following commits: Kernel Git Commit 24c25b182, Kernel Git Commit 4083d24c26, Kernel Git Commit 88114e3a96, Kernel Git Commit ba42d8a1c2, and Kernel Git Commit ccf930812f. Rebase distribution kernels onto the patched stable releases.

Workarounds

Blacklist the Nouveau driver on systems that do not require open-source NVIDIA graphics support by adding blacklist nouveau to /etc/modprobe.d/
Switch to the proprietary NVIDIA driver where policy permits, avoiding the vulnerable code path entirely
Constrain DRM device permissions to limit which local accounts can invoke the affected ioctls

bash

# Configuration example
# Blacklist Nouveau to avoid loading the vulnerable driver
echo 'blacklist nouveau' | sudo tee /etc/modprobe.d/blacklist-nouveau.conf
echo 'options nouveau modeset=0' | sudo tee -a /etc/modprobe.d/blacklist-nouveau.conf
sudo update-initramfs -u
sudo reboot