CVE-2026-98512

What it actually does

Use-after-free read in the Linux kernel nouveau driver: after nouveau_sched_destroy() frees the object containing drm_gpu_scheduler via kfree instead of kfree_rcu, a signalled fence exported via drm_syncobj/sync_file still references the freed scheduler memory; subsequent drm_sched_fence_get_timeline_name() calls (reachable via SYNC_IOC_FILE_INFO) dereference the freed slab memory.

Why it matters to the business

Systems using the nouveau driver for NVIDIA GPUs face risk of kernel memory corruption or information disclosure, which can lead to crashes, denial of service, or local privilege escalation; the flaw affects recent kernels and requires prompt patching to avoid operational disruption on GPU-equipped servers and workstations.

How an attack unfolds

An attacker creates a nouveau scheduler object and exports a fence to userspace via drm_syncobj or sync_file. After the scheduler is destroyed, the attacker invokes SYNC_IOC_FILE_INFO on the fence file descriptor; the kernel calls get_timeline_name on the dangling reference, reading from already-freed RCU-protected memory and potentially leaking kernel data or enabling further exploitation.

How to fix it

Update to a kernel containing the fix that replaces kfree(sched) with kfree_rcu(sched, rcu) in nouveau_sched_destroy(); rebuild and reboot. Until patched, restrict unprivileged access to /dev/dri and GPU device nodes via device permissions or SELinux/AppArmor policies.

How to confirm the fix worked

Confirm the presence of kfree_rcu in the nouveau_sched_destroy path in the running kernel source or binary; attempt to reproduce the KASAN slab-use-after-free report under a kernel with KASAN enabled while exercising SYNC_IOC_FILE_INFO on nouveau-backed fences; verify no crash or warning occurs after the update.

Typical attack path

1. Obtain access to a system with nouveau loaded and a compatible NVIDIA GPU
2. Create a drm_syncobj or sync_file that exports a fence backed by a nouveau_sched
3. Trigger scheduler destruction while the fence remains live
4. Call SYNC_IOC_FILE_INFO ioctl on the fence file descriptor
5. Read kernel memory via the use-after-free in get_timeline_name

How to detect it

Search kernel logs (dmesg, journalctl) for KASAN slab-use-after-free reports mentioning drm_sched_fence_get_timeline_name or nouveau_sched; inspect audit logs for frequent SYNC_IOC_FILE_INFO calls from unprivileged processes on nouveau-backed file descriptors; review crash dumps for references to freed drm_gpu_scheduler structures.

• KASAN: slab-use-after-free in drm_sched_fence_get_timeline_name
• nouveau_sched_destroy
• SYNC_IOC_FILE_INFO

What your security team should do

• Prioritize kernel updates containing the RCU fix for all systems exposing nouveau devices
• Audit and tighten permissions on /dev/dri/renderD* and /dev/dri/card* to limit unprivileged ioctl access
• Monitor kernel logs for nouveau-related KASAN or slab-use-after-free reports
• Plan staged rollout of the fixed kernel within the next maintenance window given the five-day publication age