diff options
| author | Jonghyuk Kim(MalHyuk) <malhyuk97@gmail.com> | 2026-09-02 10:27:16 +0900 |
|---|---|---|
| committer | Lyude Paul <lyude@redhat.com> | 2026-09-17 17:54:49 -0400 |
| commit | f7eae6d8d768fabd6b59779ca7da79e02c74e113 (patch) | |
| tree | e13cceb45ff787125fe86945e5343e1c2686fa04 /tools/perf/scripts/python | |
| parent | 3359a372efb6d585c97019ee1b7f1874442bcebe (diff) | |
| download | linux-next-f7eae6d8d768fabd6b59779ca7da79e02c74e113.tar.gz linux-next-f7eae6d8d768fabd6b59779ca7da79e02c74e113.zip | |
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().
Fixes: 5f03a507b29e ("drm/nouveau: implement 1:1 scheduler - entity relationship")
Cc: stable@vger.kernel.org
Signed-off-by: Jonghyuk Kim(MalHyuk) <malhyuk97@gmail.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patch.msgid.link/20260902012717.880724-1-malhyuk97@gmail.com
Diffstat (limited to 'tools/perf/scripts/python')
0 files changed, 0 insertions, 0 deletions
