---
id: "CVE-2026-98512"
kind: "vulnerability"
aliases: ["CVE-2026-98512"]
title: "Linux kernel: Nouveau GPU driver frees scheduler too early, enabling memory reads"
severity: "unknown"
cvss: null
epss: null
exploited: false
status: "open"
category: "runtime"
products: []
ecosystems: []
tags: ["gpu-workstations", "linux-kernel", "nouveau", "runtime", "shared-linux-hosts"]
not_affected_if: ["no-nvidia-gpu", "nouveau-not-loaded", "proprietary-nvidia-driver"]
published_at: "2026-10-18T16:17:02+00:00"
first_seen_at: "2026-10-23T21:57:15+00:00"
updated_at: "2026-10-25T05:25:22+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98512", "first_seen_at": "2026-10-23T21:57:15+00:00"}]
---

# Linux kernel: Nouveau GPU driver frees scheduler too early, enabling memory reads

The Nouveau GPU driver frees its scheduler object without waiting for an RCU grace period, while finished fences exported to userspace may still point to it. A local user calling SYNC_IOC_FILE_INFO can then trigger a use-after-free read of kernel memory.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- `uname -r` and compare against the fixed kernel builds listed in the NVD entry
- `lsmod | grep nouveau` to confirm the Nouveau driver is loaded
- unknown for exact affected version ranges

## Fix

- Update the Linux kernel to a release that includes the upstream commit making nouveau_sched freeing RCU-safe (`kfree_rcu()`)
- unknown for specific fixed version numbers

## Timeline

- 2026-10-23T21:57:15+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-98512

## From the sources

In the Linux kernel, the following vulnerability has been resolved:

drm/nouveau: RCU-free the scheduler-containing nouveau_sched

struct nouveau_sched embeds a struct drm_gpu_scheduler (base).
nouveau_sched_destroy() calls nouveau_sched_fini() (which does
drm_sched_fini(&sched->base)) and then frees the object with plain
kfree(sched).

drm_sched_fence_get_timeline_name() returns fence->sched->name, and the
scheduler fence keeps a .release callback so it is not ops-detached on
signalling.  A finished fence exported to userspace via drm_syncobj /
sync_file therefore keeps pointing at &sched->base after nouveau_sched_destroy(),
and a later get_timeline_name() -- reachable unprivileged through
SYNC_IOC_FILE_INFO -- dereferences freed memory (KASAN slab-use-after-free
read).

Per the dma-fence lifetime contract the exporter must keep the data backing a
signalled fence alive for an RCU grace period.  Free the scheduler-containing
object with kfree_rcu() instead of kfree().

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_