CVE-2026-98512: drm/nouveau: RCU-free the scheduler-containing nouveau_sched
In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau: RCU-free the scheduler-containing nouveausched
struct nouveausched embeds a struct drmgpuscheduler (base). nouveauscheddestroy() calls nouveauschedfini() (which does drmschedfini(&sched->base)) and then frees the object with plain kfree(sched).
drmschedfencegettimelinename() 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 drmsyncobj / syncfile therefore keeps pointing at &sched->base after nouveauscheddestroy(), and a later gettimelinename() -- reachable unprivileged through SYNCIOCFILEINFO -- 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 kfreercu() instead of kfree().
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In nouveau_sched_destroy(), free the scheduler-containing object with kfree_rcu() instead of kfree() so the signalled fence remains valid through the RCU grace period.
Event History
Frequently Asked Questions
Does triggering this issue require elevated privileges?
No. A later timeline-name lookup is reachable by an unprivileged user through SYNC_IOC_FILE_INFO, but a finished fence must first have been exported to userspace through drm_syncobj or sync_file after the associated scheduler is destroyed.
What change fixes the lifetime issue?
The scheduler-containing nouveau_sched object must be released with kfree_rcu() rather than plain kfree(). This preserves the data backing signalled fences until an RCU grace period has elapsed.