[PATCH v4 0/3] drm/sched: fix use-after-free of the fence timeline name

[Jonghyuk Kim(MalHyuk)]

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/20260902144204.1843670-1-malhyuk97@xxxxxxxxx/
Link to v2 (caching):
https://lore.kernel.org/lkml/20260902105808.1541063-1-malhyuk97@xxxxxxxxx/

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