drm/sched: fix use-after-free of the fence timeline name

drm_sched_fence_get_timeline_name() dereferences fence->sched->name. A driver that allocates a drm_gpu_scheduler per context, queue or VM frees that scheduler on context teardown, but the finished fence can outlive it: unprivileged userspace holds the exported fence via a sync_file or drm_syncobj and later queries its timeline name (e.g. SYNC_IOC_FILE_INFO), reading the freed scheduler. Same class as CVE-2025-38703 (drm/xe) and CVE-2025-71302 (drm/panthor); amdxdna, nouveau and msm (VM_BIND) are still affected in mainline, so this fixes it in the core.

v3 tried to drop the finished fence's ->release so that dma_fence detaches the ops on signalling. That turned out not to be viable:

- amdgpu dereferences to_drm_sched_fence() unconditionally (amdgpu_cs_p2_dependencies(), amdgpu_ctx_fence_time()), and ops-detach makes the helper return NULL for a signalled fence - a deterministic NULL deref reachable by an unprivileged process;
- drm/imagination uses the ops pointer as an identity test in pvr_queue_fence_is_native(), which Philipp showed would then race; and
- Christian pointed out that the reference must go from the finished to the scheduled fence, not the other way around, so v3's refcount rework was wrong.

So v4 goes back to the minimal caching fix: get_timeline_name() returns a name cached at fence init and never dereferences ->sched. Both .release callbacks, the shared allocation, the call_rcu() free and to_drm_sched_fence() all stay exactly as they are today, so there is no amdgpu/pvr regression and nothing new for the backend to reason about.

Detaching the ops is still the better fix in the long run - it is what the dma-fence rules ask for, and it would also cover get_driver_name(), which can return a string literal from a module that has since been unloaded. Patch 2 records that as a TODO entry (and a comment next to the fence ops) with the three blockers that have to be solved first, so the cleanup is not lost.

There is no unrelated formatting churn in this version; the kerneldoc reflow that was mixed into v3 is gone.

Tested with KUnit under KASAN and kmemleak (kunit.py --arch=x86_64), matched pair:

- unfixed (get_timeline_name() dereferencing ->sched):
[FAILED] drm_sched_dma_fence_uaf
BUG: KASAN: slab-use-after-free in
drm_sched_fence_get_timeline_name+0x9c/0xb0
- fixed (this series):
[PASSED] drm_sched_dma_fence_uaf
Testing complete. Ran 43 tests: passed: 43

No kmemleak reports, and the whole drm_sched suite passes with no regressions.

Link to v3 (ops-detach):
https://lore.kernel.org/lkml/[email protected]/
Link to v2 (caching):
https://lore.kernel.org/lkml/[email protected]/

v4:
- Drop the ops-detach/refcount rework; return to caching the timeline name (per the amdgpu/pvr regression above and Christian's reference-direction point).
- Add a TODO comment and a Documentation/gpu/todo.rst entry for the ops-detach cleanup (per Philipp).
- Keep Cc: stable with "we don't know since when" (per Philipp).
- No formatting-only hunks in the fix patch.
- Test suite renamed to drm_sched_dma_fence_uaf_tests for consistency with the sibling suites; re-verified under kmemleak as well as KASAN.

Jonghyuk Kim(MalHyuk) (3):
drm/sched: cache the timeline name to fix a use-after-free drm/sched: add the fence ops-detach cleanup to the TODO list drm/sched/tests: add a UAF regression test for the timeline name

 Documentation/gpu/todo.rst                    | 39 ++++++++
 drivers/gpu/drm/scheduler/sched_fence.c       | 24 ++++-
 drivers/gpu/drm/scheduler/tests/Makefile      |  1 +
 .../drm/scheduler/tests/tests_integration.c   | 88 +++++++++++++++++++
 include/drm/gpu_scheduler.h                   | 18 +++-
 5 files changed, 168 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/scheduler/tests/tests_integration.c

2.43.0