drm/sched: fix a use-after-free in get_timeline_name()

drm_sched_fence_get_timeline_name() returns fence->sched->name, and the drm_sched_fence ops keep a .release callback, so the fence is not ops-detached on signalling (dma_fence_signal_timestamp_locked() only clears ->ops for fences without .release/.wait). The callback therefore stays reachable on a long-signalled, userspace-held finished fence and unconditionally dereferences fence->sched.

A driver that allocates a drm_gpu_scheduler at per-context/per-queue/ per-VM granularity and frees it on an unprivileged context/fd close, while exporting the resulting finished fence to userspace (drm_syncobj / sync_file / dma_resv), leaves fence->sched dangling after the free. A subsequent SYNC_IOC_FILE_INFO ioctl (which calls get_timeline_name()) then reads the freed scheduler:

   BUG: KASAN: slab-use-after-free in drm_sched_fence_get_timeline_name

This is the same class as CVE-2025-38703 (drm/xe) and CVE-2025-71302 (drm/panthor), which were fixed per-driver. amdxdna, nouveau and msm (VM_BIND) are still affected in mainline, so fix it in the core to cover any per-context-scheduler driver at once.

Scheduler names are persistent strings (string literals passed to drm_sched_init()), so cache the name pointer in the fence at init time, while the scheduler is guaranteed alive, and return the cached value from get_timeline_name() without dereferencing fence->sched.

Signed-off-by Jonghyuk Kim(MalHyuk) <[email protected]>

---
  drivers/gpu/drm/scheduler/sched_fence.c | 16 +++++++++++++++-
  include/drm/gpu_scheduler.h             | 11 +++++++++++
  2 files changed, 26 insertions(+), 1 deletion(-)

drivers/gpu/drm/scheduler/sched_fence.c +15 -1

index 85ee3d694dc9..280a2d036ffd 100644
@@ -92,7 +92,13 @@ static const char *drm_sched_fence_get_driver_name(struct dma_fence *fence)
  static const char *drm_sched_fence_get_timeline_name(struct dma_fence *f)
  {
  	struct drm_sched_fence *fence = to_drm_sched_fence(f);
-	return (const char *)fence->sched->name;
+
+	/*
+	 * Do not dereference fence->sched here: a userspace-held finished
+	 * fence can outlive a per-context scheduler. Return the name cached
+	 * in drm_sched_fence_init() instead.
+	 */
+	return fence->sched_name;
  }
 
  static void drm_sched_fence_free_rcu(struct rcu_head *rcu)

@@ -228,6 +234,14 @@ void drm_sched_fence_init(struct drm_sched_fence *fence,
  	unsigned seq;
 
  	fence->sched = container_of(entity->rq, typeof(*fence->sched), rq);
+	/*
+	 * Cache the scheduler's timeline name: the finished fence may be
+	 * exported to userspace and outlive @sched (per-context schedulers
+	 * are freed on context teardown), so get_timeline_name() must not
+	 * dereference @sched. Scheduler names are persistent (string
+	 * literals passed to drm_sched_init()).
+	 */
+	fence->sched_name = fence->sched->name;
  	seq = atomic_inc_return(&entity->fence_seq);
  	dma_fence_init(&fence->scheduled, &drm_sched_fence_ops_scheduled,
  		       &fence->lock, entity->fence_context, seq);

include/drm/gpu_scheduler.h +11 -0

index d61c19e78182..4f780d70acb6 100644
@@ -305,6 +305,17 @@ struct drm_sched_fence {
           * belongs to.
           */
  	struct drm_gpu_scheduler	*sched;
+	/**
+	 * @sched_name: the timeline name of @sched, cached at init time.
+	 *
+	 * &drm_sched_fence.finished may be exported to userspace (via a
+	 * sync_file or drm_syncobj) and can outlive @sched: a driver using a
+	 * per-context scheduler frees it on context teardown while a
+	 * userspace-held finished fence still references it. The
+	 * get_timeline_name() callback must therefore not dereference @sched;
+	 * it returns this cached name instead.
+	 */
+	const char			*sched_name;
          /**
           * @lock: the lock used by the scheduled and the finished fences.
           */

It is not guaranteed in the documented contract that the name passed to drm_sched_init has to outlive the scheduler.

Hm, that might be overkill.. how about we just keep a copy of the name in the scheduler object?

+ Christian's AMD email

Quoted 9 lines · Jonghyuk Kim(MalHyuk)

drm_sched_fence_get_timeline_name() returns fence->sched->name, and the drm_sched_fence ops keep a .release callback, so the fence is not ops-detached on signalling (dma_fence_signal_timestamp_locked() only clears ->ops for fences without .release/.wait). The callback therefore stays reachable on a long-signalled, userspace-held finished fence and unconditionally dereferences fence->sched.

A driver that allocates a drm_gpu_scheduler at per-context/per-queue/ per-VM granularity and frees it on an unprivileged context/fd close,

while

Quoted 12 lines

exporting the resulting finished fence to userspace (drm_syncobj / sync_file / dma_resv), leaves fence->sched dangling after the free. A subsequent SYNC_IOC_FILE_INFO ioctl (which calls get_timeline_name()) then reads the freed scheduler:

   BUG: KASAN: slab-use-after-free in drm_sched_fence_get_timeline_name

This is the same class as CVE-2025-38703 (drm/xe) and CVE-2025-71302 (drm/panthor), which were fixed per-driver. amdxdna, nouveau and msm (VM_BIND) are still affected in mainline, so fix it in the core to cover any per-context-scheduler driver at once.

Quoted 4 lines

Scheduler names are persistent strings (string literals passed to drm_sched_init()), so cache the name pointer in the fence at init time, while the scheduler is guaranteed alive, and return the cached value from get_timeline_name() without dereferencing fence->sched.

It is not guaranteed in the documented contract that the name passed to drm_sched_init has to outlive the scheduler.

Case in point is asking "would have this patch fixed CVE-2025-38703" - to which I think answer is no. Until recent 299bc6d50b1b ("drm/xe/guc:
Keep scheduler timeline name alive") my attempt in 6bd90e700b42 ("drm/xe: Make dma-fences compliant with the safe access rules") only half fixed it by adding a RCU grace to the sched object itself, while missing the fact timeline name gets freed instantly. I haven't gotten round trying to understand why KASAN did not catch this back when I was upstreaming 6bd90e700b42.

Anyway, I think the fix will have to be to either add the full RCU grace around names in the scheduler object owning modules, or your patch plus documenting that the name passed to drm_sched_init must follow the dma-fence safe access rules (with kernel-doc cross-link and an explanation of the connection between scheduler name and dma-fence timeline name).

Hm, that might be overkill.. how about we just keep a copy of the name in the scheduler object? If we document that in gpu_scheduler.h it would fix the drivers still vulnerable, while the ones which were fixed could be simplified.

Regards,

Tvrtko

Review

Quoted 7 lines

Signed-off-by Jonghyuk Kim(MalHyuk) <[email protected]>

---
  drivers/gpu/drm/scheduler/sched_fence.c | 16 +++++++++++++++-
  include/drm/gpu_scheduler.h             | 11 +++++++++++
  2 files changed, 26 insertions(+), 1 deletion(-)

(quoted diff) +0 -0

b/drivers/gpu/drm/scheduler/sched_fence.c

drivers/gpu/drm/scheduler/sched_fence.c static const char *drm_sched_fence_get_driver_name(struct

Quoted 4 lines

index 85ee3d694dc9..280a2d036ffd 100644

drivers/gpu/drm/scheduler/sched_fence.c +0 -0

@@ -92,7 +92,13 @@ static const char *drm_sched_fence_get_driver_name(struct

dma_fence *fence)

drivers/gpu/drm/scheduler/sched_fence.c static const char *drm_sched_fence_get_driver_name(struct · line 92

Quoted 1 line

drivers/gpu/drm/scheduler/sched_fence.c +0 -0

  static const char *drm_sched_fence_get_timeline_name(struct dma_fence

*f)

drivers/gpu/drm/scheduler/sched_fence.c static const char *drm_sched_fence_get_driver_name(struct dma_fence *fence)

Quoted 7 lines

drivers/gpu/drm/scheduler/sched_fence.c +4 -1

  {
      struct drm_sched_fence *fence = to_drm_sched_fence(f);
-     return (const char *)fence->sched->name;
+
+     /*
+      * Do not dereference fence->sched here: a userspace-held finished
+      * fence can outlive a per-context scheduler. Return the name

cached

drivers/gpu/drm/scheduler/sched_fence.c void drm_sched_fence_init(struct drm_sched_fence

Quoted 7 lines

drivers/gpu/drm/scheduler/sched_fence.c +3 -0

+      * in drm_sched_fence_init() instead.
+      */
+     return fence->sched_name;
  }
 
  static void drm_sched_fence_free_rcu(struct rcu_head *rcu)

@@ -228,6 +234,14 @@ void drm_sched_fence_init(struct drm_sched_fence

*fence,

Quoted 19 lines

drivers/gpu/drm/scheduler/sched_fence.c +8 -0

      unsigned seq;
 
      fence->sched = container_of(entity->rq, typeof(*fence->sched), rq);
+     /*
+      * Cache the scheduler's timeline name: the finished fence may be
+      * exported to userspace and outlive @sched (per-context schedulers
+      * are freed on context teardown), so get_timeline_name() must not
+      * dereference @sched. Scheduler names are persistent (string
+      * literals passed to drm_sched_init()).
+      */
+     fence->sched_name = fence->sched->name;
      seq = atomic_inc_return(&entity->fence_seq);
      dma_fence_init(&fence->scheduled, &drm_sched_fence_ops_scheduled,
                     &fence->lock, entity->fence_context, seq);

include/drm/gpu_scheduler.h +0 -0

index d61c19e78182..4f780d70acb6 100644

include/drm/gpu_scheduler.h struct drm_sched_fence { · line 312

Quoted 8 lines

include/drm/gpu_scheduler.h +5 -0

@@ -305,6 +305,17 @@ struct drm_sched_fence {
           * belongs to.
           */
      struct drm_gpu_scheduler        *sched;
+     /**
+      * @sched_name: the timeline name of @sched, cached at init time.
+      *
+      * &drm_sched_fence.finished may be exported to userspace (via a
+      * sync_file or drm_syncobj) and can outlive @sched: a driver

using a

include/drm/gpu_scheduler.h struct drm_sched_fence {

Quoted 3 lines

include/drm/gpu_scheduler.h +3 -0

+      * per-context scheduler frees it on context teardown while a
+      * userspace-held finished fence still references it. The
+      * get_timeline_name() callback must therefore not dereference

@sched;

include/drm/gpu_scheduler.h struct drm_sched_fence {

Quoted 5 lines

include/drm/gpu_scheduler.h +3 -0

+      * it returns this cached name instead.
+      */
+     const char                      *sched_name;
          /**
           * @lock: the lock used by the scheduled and the finished

fences.

Quoted 1 line

include/drm/gpu_scheduler.h +0 -0

           */

Quoted 2 lines · Tvrtko Ursulin

It is not guaranteed in the documented contract that the name passed to drm_sched_init has to outlive the scheduler.

Right. Caching the bare pointer only works because every in-tree driver passes a string literal today - xe's q->name (freed with the exec queue, hence 299bc6d50b1b) is the counter-example where v1 would still dangle.

Quoted 2 lines

Hm, that might be overkill.. how about we just keep a copy of the name in the scheduler object?

The catch is the scheduler object is itself freed on context teardown, so a copy that lives there dangles for the exported fence just the same. To actually stop dereferencing ->sched the copy has to live in the fence - kstrdup in drm_sched_fence_init(), freed from the fence release. That's an alloc per fence on the submit path though.

If that overhead isn't wanted, the lighter option is to keep the pointer and document in gpu_scheduler.h that the drm_sched_init() name must follow the dma-fence safe access rules (outlive any exported fence). That matches what the already-fixed drivers do and leaves the submit path untouched.

Either one fixes amdxdna/nouveau/msm in the core. I'd lean to the documented-pointer version unless you'd rather pay the kstrdup - let me know which and I'll respin as a core-only series (fix + the kunit test).

Thanks for the 6bd90e700b42/299bc6d50b1b context, that clears up what the half-fix missed.

Quoted 17 lines · 김종혁

Quoted 2 lines · Tvrtko Ursulin

It is not guaranteed in the documented contract that the name passed to drm_sched_init has to outlive the scheduler.

Right. Caching the bare pointer only works because every in-tree driver passes a string literal today - xe's q->name (freed with the exec queue, hence 299bc6d50b1b) is the counter-example where v1 would still dangle.

Quoted 2 lines

Hm, that might be overkill.. how about we just keep a copy of the name in the scheduler object?

The catch is the scheduler object is itself freed on context teardown, so a copy that lives there dangles for the exported fence just the same. To actually stop dereferencing ->sched the copy has to live in the fence - kstrdup in drm_sched_fence_init(), freed from the fence release. That's an alloc per fence on the submit path though.

Quoted 4 lines

If that overhead isn't wanted, the lighter option is to keep the pointer and document in gpu_scheduler.h that the drm_sched_init() name must follow the dma-fence safe access rules (outlive any exported fence). That matches what the already-fixed drivers do and leaves the submit path untouched.

Quoted 6 lines

Either one fixes amdxdna/nouveau/msm in the core. I'd lean to the documented-pointer version unless you'd rather pay the kstrdup - let me know which and I'll respin as a core-only series (fix + the kunit test).

Thanks for the 6bd90e700b42/299bc6d50b1b context, that clears up what the half-fix missed.

The issue here IMO is that we are discussing working around an issue that actually stems from dma_fence not being consistently synchronized, notably because of the ops->release callback being implemented.

ops->release is de facto deprecated, precisely for reasons like these.

If we could get rid of it for sched_fence, dma_fence would take care of the decoupling of the name callbacks.

So that appears worth investigating from my POV.

To collate two replies in one:

Quoted 10 lines · Philipp Stanner

The issue here IMO is that we are discussing working around an issue that actually stems from dma_fence not being consistently synchronized, notably because of the ops->release callback being implemented.

ops->release is de facto deprecated, precisely for reasons like these.

If we could get rid of it for sched_fence, dma_fence would take care of the decoupling of the name callbacks.

Quoted 1 line

So that appears worth investigating from my POV.

I completely agree here but I am just not sure how feasible that would be. We may accept to live with the cross-documentation workaround at least as a start since even if feasible it could be a lot of work to change sched_fence like that.

Quoted 15 lines · Tvrtko Ursulin

To collate two replies in one:

Quoted 10 lines · Philipp Stanner

The issue here IMO is that we are discussing working around an issue that actually stems from dma_fence not being consistently synchronized, notably because of the ops->release callback being implemented.

ops->release is de facto deprecated, precisely for reasons like these.

If we could get rid of it for sched_fence, dma_fence would take care of the decoupling of the name callbacks.

Quoted 6 lines

Quoted 1 line

So that appears worth investigating from my POV.

I completely agree here but I am just not sure how feasible that would be. We may accept to live with the cross-documentation workaround at least as a start since even if feasible it could be a lot of work to change sched_fence like that.

It should be enough to remove ops->release for the finished_fence for now, since that's the one typically (always?) shared with userspace.

All that release cb does is drop yet another reference.

I think it's worth an investigation. Maybe 김종혁 can give it a look?

P.

Add a KUnit test that reproduces the use-after-free fixed by the previous patch. It holds a reference on a job's finished drm_sched_fence (standing in for a userspace sync_file), frees the mock scheduler, then calls get_timeline_name(). Before the fix this triggers a KASAN slab-use-after-free read of the freed scheduler; after it the test passes.

The test needs no hardware - it exercises the drm_sched core through the existing mock scheduler under KASAN.

Signed-off-by Jonghyuk Kim(MalHyuk) <[email protected]>

---
  drivers/gpu/drm/scheduler/tests/tests_basic.c | 65 ++++++++++++++++++-
  1 file changed, 64 insertions(+), 1 deletion(-)

drivers/gpu/drm/scheduler/tests/tests_basic.c +37 -0

index a5a5a35a87b0..2c6744b58f04 100644
@@ -555,9 +555,72 @@ static struct kunit_suite drm_sched_credits = {
  	.test_cases = drm_sched_credits_tests,
  };
 
+/*
+ * Reproduce the drm_sched_fence get_timeline_name() lifetime bug.
+ *
+ * drm_sched_fence_get_timeline_name() dereferences fence->sched->name, and the
+ * drm_sched_fence ops keep .release set, so the fence is NOT ops-detached on
+ * signal (unlike stub fences). A driver that frees a per-context
+ * drm_gpu_scheduler while userspace still holds the exported ->finished fence
+ * (via sync_file / drm_syncobj) leaves fence->sched dangling; reading the
+ * timeline name then touches freed slab memory (arbitrary-read once the slab is
+ * re-sprayed). Confirmed instances: amdxdna, nouveau, msm. Same class as
+ * CVE-2025-38703 (xe) and CVE-2025-71302 (panthor). KASAN reports a
+ * slab-use-after-free READ in drm_sched_fence_get_timeline_name.
+ */
+static void drm_sched_fence_get_timeline_name_uaf(struct kunit *test)
+{
+	struct drm_mock_sched_entity *entity;
+	struct drm_mock_scheduler *sched;
+	struct drm_mock_sched_job *job;
+	struct dma_fence *finished;
+	const char *name;
+	bool done;
+
+	sched = drm_mock_sched_new(test, MAX_SCHEDULE_TIMEOUT);
+	entity = drm_mock_sched_entity_new(test, DRM_SCHED_PRIORITY_NORMAL,
+					   sched);
+	job = drm_mock_sched_job_new(test, entity);
+
+	/* Arm + submit first; the s_fence is only created by drm_sched_job_arm(). */
+	drm_mock_sched_job_submit(job);
+
+	/* Independent reference on the finished fence == userspace sync_file. */
+	finished = dma_fence_get(&job->base.s_fence->finished);
+
+	/* Let the job get picked up (hw_fence created), then signal + finish. */
+	done = drm_mock_sched_job_wait_scheduled(job, HZ);
+	KUNIT_ASSERT_TRUE(test, done);
+	drm_mock_sched_advance(sched, 1);

drivers/gpu/drm/scheduler/tests/tests_basic.c +17 -1

+	kunit_info(test, "get_timeline_name() on stale fence returned %p\n", name);
+
+	dma_fence_put(finished);
+}
+
+static struct kunit_case drm_sched_fence_uaf_tests[] = {
+	KUNIT_CASE(drm_sched_fence_get_timeline_name_uaf),
+	{}
+};
+
+static struct kunit_suite drm_sched_fence_uaf = {
+	.name = "drm_sched_fence_uaf_tests",
+	.test_cases = drm_sched_fence_uaf_tests,
+};
+
  kunit_test_suites(&drm_sched_basic,
  		  &drm_sched_timeout,
  		  &drm_sched_cancel,
  		  &drm_sched_priority,
  		  &drm_sched_modify_sched,
-		  &drm_sched_credits);
+		  &drm_sched_credits,
+		  &drm_sched_fence_uaf);