In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: RCU-free the…

Why it is Yellow

• CVSS 7.1 high
• On your watchlist: linux kernel

References

• https://git.kernel.org/stable/c/35151e9a8274174ccbb92e3b3ba7dc7a008dcada
• https://git.kernel.org/stable/c/40edf5eefc3fd94592a91d6eb074d4fc6f606c75
• https://git.kernel.org/stable/c/cd6e11b6ebe04a0a1f1435df561acada9eadc563
• https://git.kernel.org/stable/c/f7eae6d8d768fabd6b59779ca7da79e02c74e113

Original description

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().