Cloudanix VulnDB

CVE-2026-68271

None

CVSS

—

EPSS

0.2%

Published

Aug 10, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux graphics driver can make the computer crash or waste memory when certain operations fail.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Incorrect ordering of error cleanup labels in nouveau_uvmm_vm_bind_ucopy() and nouveau_exec_ucopy() causes ERR_PTR values from failed u_memcpya() calls to be passed to kvfree() or leaves allocations unfreed, resulting in invalid pointer dereference or memory leak.

Why it matters to the business

Systems using the nouveau driver may experience kernel crashes or gradual memory exhaustion, reducing availability and stability for workloads involving NVIDIA GPUs; low exploitability and declining EPSS indicate limited immediate risk but still warrant patching.

How an attack unfolds

An attacker with local access invokes the affected ucopy functions so that u_memcpya() fails on in_sync.s or out_sync.s; the wrong goto targets then either dereference an ERR_PTR or skip freeing prior allocations, triggering a kernel oops or leak.

How to fix it

Upgrade to a Linux kernel containing the corrected cleanup label ordering; apply the upstream fix that swaps err_free_ops/err_free_pushs and err_free_ins to free resources in reverse allocation order.

How to confirm the fix worked

Inspect the patched kernel source to confirm cleanup labels now free allocations in reverse order; reproduce allocation-failure paths and verify no oops or leaks occur; monitor dmesg for absence of nouveau-related invalid dereferences.

Typical attack path

  1. Obtain local execution on a system using the nouveau driver
  2. Trigger nouveau_uvmm_vm_bind_ucopy or nouveau_exec_ucopy with an allocation that fails
  3. Force the reversed cleanup path to dereference ERR_PTR or leak memory
  4. Cause kernel oops or resource exhaustion

How to detect it

Search kernel logs and dmesg for nouveau oops messages referencing u_memcpya, err_free_ops, err_free_pushs, or err_free_ins; correlate with processes that invoke vm_bind or exec operations on nouveau devices.

What your security team should do

  • Prioritize kernel updates on systems exposing the nouveau driver
  • Review logs for nouveau oops signatures while patches are applied
  • Limit untrusted local code execution on affected hosts until remediated

The record

In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix reversed error cleanup order in ucopy functions nouveau_uvmm_vm_bind_ucopy() and nouveau_exec_ucopy() place their error cleanup labels in allocation order rather than reverse allocation order. On a u_memcpya() failure for in_sync.s, the goto to err_free_ops (or err_free_pushs) frees the first allocation and then falls through to err_free_ins, which calls u_free() on args->in_sync.s. Since args->in_sync.s still holds the ERR_PTR returned by the failed u_memcpya(), and ERR_PTR values are not caught by ZERO_OR_NULL_PTR(), kvfree() proceeds to dereference it, which can result in a kernel oops. A failure for out_sync.s instead jumps to err_free_ins and skips freeing the first allocation, leading to a memory leak. Fix by swapping the cleanup label order so resources are freed in the correct reverse allocation sequence.

Affected packages

Ecosystem Package Introduced Fixed