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] Missing RCU grace period before freeing the drm_gpu_scheduler leads to Use-After-Free.
--

commit 11a9a68f368e39faaeb53298fa915ab4e38a08eb
Author: Christian König <ckoenig.leichtzumerken@gmail.com>

drm/sched: document the RCU dependency

This commit adds documentation to drm_sched_fini() noting that an RCU grace
period is necessary between signaling the last scheduler fence and tearing
down the scheduler. It clarifies the consequences of adding RCU protection
to the returned strings from dma_fence backends.

> diff --git a/drivers/gpu/drm/scheduler/sched_main.c b/drivers/gpu/drm/scheduler/sched_main.c
> index 6cb6f95464938..22103cb077824 100644
> --- a/drivers/gpu/drm/scheduler/sched_main.c
> +++ b/drivers/gpu/drm/scheduler/sched_main.c
> @@ -1203,6 +1203,10 @@ 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 scheduler fences timeline name is returned protected by the signaled
> + * status and RCU, so an RCU grace period is necessary between signaling the
> + * last scheduler fence and tearing down the scheduler who originated it.
>   */
>  void drm_sched_fini(struct drm_gpu_scheduler *sched)
>  {

[Severity: High]
This isn't a bug introduced by this patch, but since we are documenting the
RCU grace period requirement here, does drm_sched_fini() or its callers
actually enforce this grace period?

Looking at several drivers, the scheduler memory is freed synchronously
immediately after calling drm_sched_fini() without an intervening
synchronize_rcu(). For example, in panthor_vm_destroy()
(drivers/gpu/drm/panthor/panthor_mmu.c):

    drm_sched_entity_destroy(&vm->entity);
    drm_sched_fini(&vm->sched);
    /* ... */
    kfree(vm);

Similarly, in aie2_hwctx_fini() (drivers/accel/amdxdna/aie2_ctx.c) and
msm_gem_vm_close() (drivers/gpu/drm/msm/msm_gem_vma.c), the scheduler
memory is freed synchronously after calling drm_sched_fini().

Since unprivileged userspace can control the creation and destruction of
VMs and contexts via standard driver ioctls, could this lead to a
use-after-free? Concurrently, the RCU read-side critical section in
dma_fence_get_timeline_name() can access the freed scheduler pointer
(fence->sched->name). Should synchronize_rcu() be added, or the free
deferred using kfree_rcu(), to prevent this UAF?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260909131808.2201-1-christian.koenig@amd.com?part=2