Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] The documented RCU grace period requirement for scheduler teardown is insufficient to prevent Use-After-Free, and the underlying UAF remains reachable from userspace. -- commit 5a72d906ede5cec7818892f2331889b7b0dd6420 Author: Christian König <[email protected]> drm/sched: document the RCU dependency This commit documents the requirement to wait for an RCU grace period between signaling the last hardware fence and tearing down the scheduler. > diff --git a/drivers/gpu/drm/scheduler/sched_main.c > b/drivers/gpu/drm/scheduler/sched_main.c > --- a/drivers/gpu/drm/scheduler/sched_main.c > +++ b/drivers/gpu/drm/scheduler/sched_main.c > @@ -1203,6 +1203,11 @@ static void drm_sched_cancel_remaining_jobs(struct > drm_gpu_scheduler *sched) > * is implemented, all jobs will be canceled through it and afterwards > cleaned > * up through &struct drm_sched_backend_ops.free_job. If cancel_job is not > * implemented, memory could leak. > + * > + * The user must wait one RCU grace period between signaling the last > hardware- > + * fence and calling this function because the timeline name returned by > + * scheduler fences must stay valid until all readers have exited their RCU > read > + * side critical section. > */ > void drm_sched_fini(struct drm_gpu_scheduler *sched) [Severity: High] This is a pre-existing issue, but is waiting a single RCU grace period before calling drm_sched_fini() actually sufficient to prevent a use-after-free here? If a user submits a job to obtain a sync_file fd for the scheduler fence, and then the GPU queue or context is destroyed while jobs are pending (leaving fences unsignaled), drivers like xe will tear down the scheduler and often free the embedding structure without waiting for an RCU grace period: drivers/gpu/drm/xe/xe_execlist.c:execlist_exec_queue_fini() { ... drm_sched_fini(&exl->sched); ... kfree(exl); } Since the fence doesn't detach from the scheduler, a subsequent userspace query via SYNC_IOC_FILE_INFO will enter a new RCU read-side critical section and access the timeline name on a fence that has outlived its scheduler: drivers/dma-buf/sync_file.c:sync_fill_fence_info() { ... rcu_read_lock(); ... timeline = dma_fence_timeline_name(fence); ... } Which then blindly dereferences the freed scheduler pointer: drivers/gpu/drm/scheduler/sched_fence.c:drm_sched_fence_get_timeline_name() { ... return (const char *)fence->sched->name; } Even if the driver waited for an RCU grace period before calling drm_sched_fini(), couldn't new RCU readers still start querying the unsignaled fence through sync_file long after the scheduler is freed? -- Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=2
