Bug 2554846 (CVE-2026-98512) - CVE-2026-98512 kernel: drm/nouveau: RCU-free the scheduler-containing nouveau_sched
Summary: CVE-2026-98512 kernel: drm/nouveau: RCU-free the scheduler-containing nouveau...
Keywords:
Status: NEW
Alias: CVE-2026-98512
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Product Security DevOps Team
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-10-18 15:22 UTC by OSIDB Bzimport
Modified: 2026-10-19 12:49 UTC (History)
17 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

Description OSIDB Bzimport 2026-10-18 15:22:36 UTC
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().


Note You need to log in before you can comment on or make changes to this bug.