Re: [PATCH 2/2] drm/sched: document the RCU dependency

[sashiko-bot@kernel.org]

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 <ckoenig.leichtzumerken@gmail.com>

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/20260914182740.1587-1-christian.koenig@amd.com?part=2