On 9/10/26 21:37, [email protected] wrote:
> [Critical] Potential Use-After-Free of `sched` and `sched->sched_rq` if
> `drm_sched_fini()` is called with pending jobs and `own_submit_wq` is false.
The chain is there in the scheduler. drm_sched_start() queues work_run_job
unconditionally, and drm_sched_fini() destroys submit_wq only when it owns it,
so a timeout handler restarting the scheduler during teardown could leave work
behind that later reads sched->sched_rq[i].
No in-tree driver reaches it. Of the four that pass their own submit_wq:
- panthor sets .timeout = MAX_SCHEDULE_TIMEOUT on both its schedulers, which
drm_sched_start_timeout() tests before anything else, so the TDR never arms;
- powervr refcounts the context, and pvr_queue_destroy() runs only after the
last reference is dropped, which in-flight jobs hold;
- nouveau waits on nouveau_sched_job_list_empty() before drm_sched_fini();
- xe never calls drm_sched_start().
Both drivers named in the report are covered, for different reasons. So there
is nothing here for this patch, which only moves the run queue frees within
drm_sched_fini().
The one thing worth recording is that the protection is per-driver rather than
structural. A driver combining its own submit_wq, a finite timeout, and
drm_sched_start() in timedout_job would have to drain before teardown itself.
Regards,
Donggeun
