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 <[email protected]> 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/[email protected]?part=2
