[PATCH v4 1/3] drm/sched: cache the timeline name to fix a use-after-free

[PATCH v4 1/3] drm/sched: cache the timeline name to fix a use-after-free

[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
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.

Cache the scheduler's 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. The timeline name
is not guaranteed by the contract to outlive the scheduler, so document in
struct drm_sched_init_args that the @name passed to drm_sched_init() must
follow the dma-fence safe access rules and outlive any exported fence.
Every in-tree driver passes a string literal, which satisfies this;
commit 299bc6d50b1b ("drm/xe/guc: Keep scheduler timeline name alive")
keeps drm/xe's dynamically-allocated name alive across the RCU grace and
can be simplified on top of this.

Fixes: 506aa8b02a8d ("dma-fence: Add safe access helpers and document the rules")
Cc: stable@vger.kernel.org # we don't know since when
Signed-off-by: Jonghyuk Kim(MalHyuk) <malhyuk97@gmail.com>
---
 drivers/gpu/drm/scheduler/sched_fence.c | 24 +++++++++++++++++++++++-
 include/drm/gpu_scheduler.h             | 18 +++++++++++++++++-
 2 files changed, 40 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/scheduler/sched_fence.c b/drivers/gpu/drm/scheduler/sched_fence.c
index 096fe28aa9c9..b2a842a1c9ba 100644
--- a/drivers/gpu/drm/scheduler/sched_fence.c
+++ b/drivers/gpu/drm/scheduler/sched_fence.c
@@ -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)
@@ -180,6 +186,14 @@ static void drm_sched_fence_set_deadline_finished(struct dma_fence *f,
 		dma_fence_set_deadline(parent, deadline);
 }
 
+/*
+ * TODO: Both fences implement .release, so dma_fence keeps their ops attached
+ * after signalling. Dropping the callbacks would let dma_fence detach the ops,
+ * after which neither get_timeline_name() nor get_driver_name() can run against
+ * a freed scheduler or an unloaded module - the complete fix. It first requires
+ * auditing every to_drm_sched_fence() caller, since ops-detach makes the helper
+ * return NULL for a signalled fence. See Documentation/gpu/todo.rst.
+ */
 static const struct dma_fence_ops drm_sched_fence_ops_scheduled = {
 	.get_driver_name = drm_sched_fence_get_driver_name,
 	.get_timeline_name = drm_sched_fence_get_timeline_name,
@@ -228,6 +242,14 @@ void drm_sched_fence_init(struct drm_sched_fence *fence,
 	unsigned seq;
 
 	fence->sched = entity->rq->sched;
+	/*
+	 * 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. The name is required to outlive any exported
+	 * fence (see @name in struct drm_sched_init_args).
+	 */
+	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);
diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
index 7a64cc11de08..412b8c4643f1 100644
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@ -322,6 +322,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.
          */
@@ -646,7 +657,12 @@ struct drm_gpu_scheduler {
  * @timeout: timeout value in jiffies for submitted jobs.
  * @timeout_wq: workqueue to use for timeout work. If NULL, the system_wq is used.
  * @score: score atomic shared with other schedulers. May be NULL.
- * @name: name (typically the driver's name). Used for debugging
+ * @name: name (typically the driver's name). Used for debugging, and as the
+ *	dma-fence timeline name of the scheduler's fences. It must follow the
+ *	dma-fence safe access rules: a &drm_sched_fence.finished exported to
+ *	userspace can outlive the scheduler, so @name has to outlive any such
+ *	fence - use a string literal, or free it only after an RCU grace period
+ *	past the last exported fence. See drm_sched_fence_get_timeline_name().
  * @dev: associated device. Used for debugging
  */
 struct drm_sched_init_args {
-- 
2.43.0

Re: [PATCH v4 1/3] drm/sched: cache the timeline name to fix a use-after-free

[Christian König]

On 9/4/26 10:06, Jonghyuk Kim(MalHyuk) wrote:
> 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.
> 
> Cache the scheduler's 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. The timeline name
> is not guaranteed by the contract to outlive the scheduler, so document in
> struct drm_sched_init_args that the @name passed to drm_sched_init() must
> follow the dma-fence safe access rules and outlive any exported fence.
> Every in-tree driver passes a string literal, which satisfies this;
> commit 299bc6d50b1b ("drm/xe/guc: Keep scheduler timeline name alive")
> keeps drm/xe's dynamically-allocated name alive across the RCU grace and
> can be simplified on top of this.
> 
> Fixes: 506aa8b02a8d ("dma-fence: Add safe access helpers and document the rules")
> Cc: stable@vger.kernel.org # we don't know since when
> Signed-off-by: Jonghyuk Kim(MalHyuk) <malhyuk97@gmail.com>
> ---
>  drivers/gpu/drm/scheduler/sched_fence.c | 24 +++++++++++++++++++++++-
>  include/drm/gpu_scheduler.h             | 18 +++++++++++++++++-
>  2 files changed, 40 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/scheduler/sched_fence.c b/drivers/gpu/drm/scheduler/sched_fence.c
> index 096fe28aa9c9..b2a842a1c9ba 100644
> --- a/drivers/gpu/drm/scheduler/sched_fence.c
> +++ b/drivers/gpu/drm/scheduler/sched_fence.c
> @@ -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;

I don't think that this actually solves the problem, the sched_name still needs to be kept alive until all fences are destroyed and that is something drivers don't want/can do.

>  }
>  
>  static void drm_sched_fence_free_rcu(struct rcu_head *rcu)
> @@ -180,6 +186,14 @@ static void drm_sched_fence_set_deadline_finished(struct dma_fence *f,
>  		dma_fence_set_deadline(parent, deadline);
>  }
>  
> +/*
> + * TODO: Both fences implement .release, so dma_fence keeps their ops attached
> + * after signalling. Dropping the callbacks would let dma_fence detach the ops,
> + * after which neither get_timeline_name() nor get_driver_name() can run against
> + * a freed scheduler or an unloaded module - the complete fix. It first requires
> + * auditing every to_drm_sched_fence() caller, since ops-detach makes the helper
> + * return NULL for a signalled fence. See Documentation/gpu/todo.rst.
> + */

That sounds like a bad idea as well.

Dropping the fence->ops is to detach the fence from the module which originally issued it and not solve lifetime problems between the scheduler and the driver.

I think we should rather re-consider patch 035219a760edb35ae9a9e96beba7f122e26a997b ("dma-buf: dma-fence: Fix potential NULL pointer dereference"):

Here we changed the check in dma_fence_driver_name() and dma_fence_timeline_name():

@@ -1167,7 +1167,7 @@ const char __rcu *dma_fence_driver_name(struct dma_fence *fence)
 
        /* RCU protection is required for safe access to returned string */
        ops = rcu_dereference(fence->ops);
-       if (!dma_fence_test_signaled_flag(fence))
+       if (ops)
                return (const char __rcu *)ops->get_driver_name(fence);
        else
                return (const char __rcu *)"detached-driver";

The problem is that we didn't considered that there a fence implementations which still have a release or wait callbacks but rely on not needing to return a string for a signaled fence.

Regards,
Christian.

Re: [PATCH v4 1/3] drm/sched: cache the timeline name to fix a use-after-free

[Philipp Stanner]

On Fri, 2026-09-04 at 10:20 +0200, Christian König wrote:
> 

[…]

> >  
> > +/*
> > + * TODO: Both fences implement .release, so dma_fence keeps their ops attached
> > + * after signalling. Dropping the callbacks would let dma_fence detach the ops,
> > + * after which neither get_timeline_name() nor get_driver_name() can run against
> > + * a freed scheduler or an unloaded module - the complete fix. It first requires
> > + * auditing every to_drm_sched_fence() caller, since ops-detach makes the helper
> > + * return NULL for a signalled fence. See Documentation/gpu/todo.rst.
> > + */
> 
> That sounds like a bad idea as well.
> 
> Dropping the fence->ops is to detach the fence from the module which originally issued it and not solve lifetime problems between the scheduler and the driver.

It can be used to solve that problem though, can it not?

The underlying problem is that the driver has no chance to figure out
when the scheduler is actually done with all the sched_fences.

Remember our lengthy discussions about drm_sched_fini(). Maybe we want
to reconsider providing a function with which the driver can wait until
the scheduler is done with all finished_fences?

> 
> I think we should rather re-consider patch 035219a760edb35ae9a9e96beba7f122e26a997b ("dma-buf: dma-fence: Fix potential NULL pointer dereference"):
> 
> Here we changed the check in dma_fence_driver_name() and dma_fence_timeline_name():
> 
> @@ -1167,7 +1167,7 @@ const char __rcu *dma_fence_driver_name(struct dma_fence *fence)
>  
>         /* RCU protection is required for safe access to returned string */
>         ops = rcu_dereference(fence->ops);
> -       if (!dma_fence_test_signaled_flag(fence))
> +       if (ops)
>                 return (const char __rcu *)ops->get_driver_name(fence);
>         else
>                 return (const char __rcu *)"detached-driver";
> 
> The problem is that we didn't considered that there a fence implementations which still have a release or wait callbacks but rely on not needing to return a string for a signaled fence.
> 

Could we move the signaled check to amdgpu and pvr?

IOW, we keep the solution presented here (removing ops->release for
finished-fence) and the few drivers that check whether a fence is their
own first do a locked dma_fence_is_signaled() check?


P.

Re: [PATCH v4 1/3] drm/sched: cache the timeline name to fix a use-after-free

[Christian König]

On 9/4/26 10:31, Philipp Stanner wrote:
> On Fri, 2026-09-04 at 10:20 +0200, Christian König wrote:
>>
> 
> […]
> 
>>>  
>>> +/*
>>> + * TODO: Both fences implement .release, so dma_fence keeps their ops attached
>>> + * after signalling. Dropping the callbacks would let dma_fence detach the ops,
>>> + * after which neither get_timeline_name() nor get_driver_name() can run against
>>> + * a freed scheduler or an unloaded module - the complete fix. It first requires
>>> + * auditing every to_drm_sched_fence() caller, since ops-detach makes the helper
>>> + * return NULL for a signalled fence. See Documentation/gpu/todo.rst.
>>> + */
>>
>> That sounds like a bad idea as well.
>>
>> Dropping the fence->ops is to detach the fence from the module which originally issued it and not solve lifetime problems between the scheduler and the driver.
> 
> It can be used to solve that problem though, can it not?

Yes, but I think forcing dma_fence implementations to drop their release callback to fix lifetime problems with the driver and timeline name functions is a bad idea.

We should keep this fix simple and focused so that we can easily backport it.

Fixing all dma_fence implementations to not need the release callback is something I really like to have as well, but not to fix this issue here. 

> 
> The underlying problem is that the driver has no chance to figure out
> when the scheduler is actually done with all the sched_fences.
> 
> Remember our lengthy discussions about drm_sched_fini(). Maybe we want
> to reconsider providing a function with which the driver can wait until
> the scheduler is done with all finished_fences?

The problem is that won't help unless we either add more checks or fix the checks in dma_fence_driver_name()/dma_fence_timeline_name().

The dma_fence object can trivially outlive both the driver and the scheduler instance it originally issued.

>>
>> I think we should rather re-consider patch 035219a760edb35ae9a9e96beba7f122e26a997b ("dma-buf: dma-fence: Fix potential NULL pointer dereference"):
>>
>> Here we changed the check in dma_fence_driver_name() and dma_fence_timeline_name():
>>
>> @@ -1167,7 +1167,7 @@ const char __rcu *dma_fence_driver_name(struct dma_fence *fence)
>>  
>>         /* RCU protection is required for safe access to returned string */
>>         ops = rcu_dereference(fence->ops);
>> -       if (!dma_fence_test_signaled_flag(fence))
>> +       if (ops)
>>                 return (const char __rcu *)ops->get_driver_name(fence);
>>         else
>>                 return (const char __rcu *)"detached-driver";
>>
>> The problem is that we didn't considered that there a fence implementations which still have a release or wait callbacks but rely on not needing to return a string for a signaled fence.
>>
> 
> Could we move the signaled check to amdgpu and pvr?

Yes we could. I also considered that. But I would rather like to see it handled in the common dma_fence code.

If I remember correctly either Tvrko, you or somebody else was in favor of doing "if (!dma_fence_test_signaled_flag(fence) && ops)" here but I though that this was unnecessary and we would rather remove the release callbacks. Maybe I was wrong with that.
> IOW, we keep the solution presented here (removing ops->release for
> finished-fence) and the few drivers that check whether a fence is their
> own first do a locked dma_fence_is_signaled() check?

Works for me as well, but as I said I would rather like to keep it simple and stupid for backporting.

Regards,
Christian.

> 
> 
> P.

Re: [PATCH v4 1/3] drm/sched: cache the timeline name to fix a use-after-free

[Philipp Stanner]

On Fri, 2026-09-04 at 14:49 +0200, Christian König wrote:
> On 9/4/26 10:31, Philipp Stanner wrote:
> > On Fri, 2026-09-04 at 10:20 +0200, Christian König wrote:
> > > 

[…]

> > > 
> > > That sounds like a bad idea as well.
> > > 
> > > Dropping the fence->ops is to detach the fence from the module
> > > which originally issued it and not solve lifetime problems
> > > between the scheduler and the driver.
> > 
> > It can be used to solve that problem though, can it not?
> 
> Yes, but I think forcing dma_fence implementations to drop their
> release callback to fix lifetime problems with the driver and
> timeline name functions is a bad idea.

The issue we're facing is not so much related with life times, is it?

Even if the driver correctly tears down the scheduler (i.e., signal all
hardware fences), this problem still exists.

> 
> We should keep this fix simple and focused so that we can easily backport it.

My hope would be that the dma_fence backend solution can be used that
*already exists*. That could then both be simple and maintainable.


Correct me if I'm wrong, but it seems we have not found an alternative
solution that can work yet?

> 
> Fixing all dma_fence implementations to not need the release callback
> is something I really like to have as well, but not to fix this issue
> here. 
> 
> > 
> > The underlying problem is that the driver has no chance to figure out
> > when the scheduler is actually done with all the sched_fences.
> > 
> > Remember our lengthy discussions about drm_sched_fini(). Maybe we want
> > to reconsider providing a function with which the driver can wait until
> > the scheduler is done with all finished_fences?
> 
> The problem is that won't help unless we either add more checks or
> fix the checks in dma_fence_driver_name()/dma_fence_timeline_name().
> 
> The dma_fence object can trivially outlive both the driver and the
> scheduler instance it originally issued.

Right.

> 
> > > 
> > > I think we should rather re-consider patch
> > > 035219a760edb35ae9a9e96beba7f122e26a997b ("dma-buf: dma-fence:
> > > Fix potential NULL pointer dereference"):
> > > 
> > > Here we changed the check in dma_fence_driver_name() and
> > > dma_fence_timeline_name():
> > > 
> > > @@ -1167,7 +1167,7 @@ const char __rcu *dma_fence_driver_name(struct dma_fence *fence)
> > >  
> > >         /* RCU protection is required for safe access to returned string */
> > >         ops = rcu_dereference(fence->ops);
> > > -       if (!dma_fence_test_signaled_flag(fence))
> > > +       if (ops)
> > >                 return (const char __rcu *)ops->get_driver_name(fence);
> > >         else
> > >                 return (const char __rcu *)"detached-driver";
> > > 
> > > The problem is that we didn't considered that there a fence
> > > implementations which still have a release or wait callbacks but
> > > rely on not needing to return a string for a signaled fence.
> > > 
> > 
> > Could we move the signaled check to amdgpu and pvr?
> 
> Yes we could. I also considered that. But I would rather like to see
> it handled in the common dma_fence code.
> 
> If I remember correctly either Tvrko, you or somebody else was in
> favor of doing "if (!dma_fence_test_signaled_flag(fence) && ops)"
> here but I though that this was unnecessary and we would rather
> remove the release callbacks. Maybe I was wrong with that.

I hope that wasn't me because that again looks very racy.

I think that there is no way around using the spinlock. As I have
pointed out many times, the fact that the signaled-bit is set with lock
protection and read without it is fundamentally broken :(

> > IOW, we keep the solution presented here (removing ops->release for
> > finished-fence) and the few drivers that check whether a fence is
> > their
> > own first do a locked dma_fence_is_signaled() check?
> 
> Works for me as well, but as I said I would rather like to keep it
> simple and stupid for backporting.

If you can think of a stupid and simple solution, shoot. The only thing
I can think of is moving the string into the dma_fence, as a hard copy
:)


In the mean time, my proposal is to keep aiming for removing
sched_fence->ops->release and fixing pvr and amdgpu.

I think that will have to entail a signaled-check. Question would then
be whether we place it in the driver or the backend.


P.

Re: [PATCH v4 1/3] drm/sched: cache the timeline name to fix a use-after-free

[Tvrtko Ursulin]

On 04/09/2026 20:06, Philipp Stanner wrote:

8><

> If you can think of a stupid and simple solution, shoot. The only thing
> I can think of is moving the string into the dma_fence, as a hard copy
> :)
> 
> 
> In the mean time, my proposal is to keep aiming for removing
> sched_fence->ops->release and fixing pvr and amdgpu.

Fixing the drivers sounds like an obvious thing to try indeed. Along the 
same lines as it was done for xe and panthor. It is an already 
established and well understood approach so shouldn't be controversial. 
After that we can discuss in leisurely pace if something better is 
possible in the scheduler core.

I understand its amdxdna, nouveau, and msm. Was it attempted so far? Is 
it significantly more complicated than it was for panthor and xe?

As for regarding the 035219a760ed ("dma-buf: dma-fence: Fix potential 
NULL pointer dereference") sub-thread - I did not manage to penetrate 
the consensus there - whether it was established that it needs adding 
the is signaled check back (with additional memory barriers, like v1 of 
that patch) or not? Regardless of fixing the drivers or what?

Regards,

Tvrtko

Re: [PATCH v4 1/3] drm/sched: cache the timeline name to fix a use-after-free

[Philipp Stanner]

On Mon, 2026-09-07 at 10:15 +0100, Tvrtko Ursulin wrote:
> 
> 
> On 04/09/2026 20:06, Philipp Stanner wrote:
> 
> 8><
> 
> > If you can think of a stupid and simple solution, shoot. The only thing
> > I can think of is moving the string into the dma_fence, as a hard copy
> > :)
> > 
> > 
> > In the mean time, my proposal is to keep aiming for removing
> > sched_fence->ops->release and fixing pvr and amdgpu.
> 
> Fixing the drivers sounds like an obvious thing to try indeed. Along the 
> same lines as it was done for xe and panthor. It is an already 
> established and well understood approach so shouldn't be controversial. 
> After that we can discuss in leisurely pace if something better is 
> possible in the scheduler core.
> 
> I understand its amdxdna, nouveau, and msm. Was it attempted so far? Is 
> it significantly more complicated than it was for panthor and xe?

How did the others fix that?

If we look at nouveau:

static void
nouveau_sched_fini(struct nouveau_sched *sched)
{
 struct drm_gpu_scheduler *drm_sched = &sched->base;
 struct drm_sched_entity *entity = &sched->entity;

 wait_event(sched->job.wq, nouveau_sched_job_list_empty(sched));

 drm_sched_entity_fini(entity);
 drm_sched_fini(drm_sched);

 /* Destroy workqueue after scheduler tear down, otherwise it might still
 * be in use.
 */
 if (sched->wq)
 destroy_workqueue(sched->wq);
}


We see that it
   1. stops accepting jobs from userspace (not visible here)
   2. waits until all hardware fences in this ring are signaled
   3. only then tears down drm_sched

Then nouveau might unload or free up resources.

The nasty thing is that I don't see how nouveau misbehaves here and how
the stuff might be fixed.

The problem is that the sched_fence implements ops->release, so the
check doesn't take effect.

Moreover, even if we did remove ops->release in drm_sched, it would
still be a race: a driver's contract is the hardware_fence, the rule
being that you have to signal those. So after signaling the last
hardware_fence, you could actually start releasing resources, but it
might be that finished_fences are still in-flight and are unsignaled.

So we have some sort of fence -> fence race here, too.

> 
> As for regarding the 035219a760ed ("dma-buf: dma-fence: Fix potential
> NULL pointer dereference") sub-thread - I did not manage to penetrate
> the consensus there - whether it was established that it needs adding
> the is signaled check back (with additional memory barriers, like v1 of 
> that patch) or not? Regardless of fixing the drivers or what?


As far as my understanding goes this is the only way to get this right
for everyone, i.e. also users who implement ops->release(). Then at
least the driver could unload after signalling all its fences (with the
exception of those who have a shared spinlock maybe).


However, I suppose then we would then have two mechanisms, one dancing
with RCU around the ops pointer, the other checking whether the fence
is signaled, presumably with manual ordering through barriers.

My first guess would be that maybe we should only rely on the signaled-
state and leave the ops-pointer untouched? This should also work for
pvr, notably.


P.

Re: [PATCH v4 1/3] drm/sched: cache the timeline name to fix a use-after-free

[Philipp Stanner]

On Mon, 2026-09-07 at 11:42 +0200, Philipp Stanner wrote:
> Moreover, even if we did remove ops->release in drm_sched, it would
> still be a race: a driver's contract is the hardware_fence, the rule
> being that you have to signal those. So after signaling the last
> hardware_fence, you could actually start releasing resources, but it
> might be that finished_fences are still in-flight and are unsignaled.
> 
> So we have some sort of fence -> fence race here, too.

Forget about that, signaling the hw_fence should always result in
undelayed signaling of the finished-fence.

So it would seem that making the signaled-state instead of ops == NULL
the decoupling point in dma_fence is the solution to go for?


P.

Re: [PATCH v4 1/3] drm/sched: cache the timeline name to fix a use-after-free

[Tvrtko Ursulin]

On 07/09/2026 10:42, Philipp Stanner wrote:
> On Mon, 2026-09-07 at 10:15 +0100, Tvrtko Ursulin wrote:
>>
>>
>> On 04/09/2026 20:06, Philipp Stanner wrote:
>>
>> 8><
>>
>>> If you can think of a stupid and simple solution, shoot. The only thing
>>> I can think of is moving the string into the dma_fence, as a hard copy
>>> :)
>>>
>>>
>>> In the mean time, my proposal is to keep aiming for removing
>>> sched_fence->ops->release and fixing pvr and amdgpu.
>>
>> Fixing the drivers sounds like an obvious thing to try indeed. Along the
>> same lines as it was done for xe and panthor. It is an already
>> established and well understood approach so shouldn't be controversial.
>> After that we can discuss in leisurely pace if something better is
>> possible in the scheduler core.
>>
>> I understand its amdxdna, nouveau, and msm. Was it attempted so far? Is
>> it significantly more complicated than it was for panthor and xe?
> 
> How did the others fix that?

Combination of kfree_rcu, synchronize_rcu and storing the name in an 
object protected by those:

6bd90e700b42 ("drm/xe: Make dma-fences compliant with the safe access 
rules")
299bc6d50b1b ("drm/xe/guc: Keep scheduler timeline name alive")
efe24898485c ("drm/panthor: fix for dma-fence safe access rules")

Not too complicated on the overall. Simply ensure RCU grace period 
between signaling the hw fence and freeing the ops, scheduler, name, all 
that it is in the externally accessible dereference chain.

> If we look at nouveau:
> 
> static void
> nouveau_sched_fini(struct nouveau_sched *sched)
> {
>   struct drm_gpu_scheduler *drm_sched = &sched->base;
>   struct drm_sched_entity *entity = &sched->entity;
> 
>   wait_event(sched->job.wq, nouveau_sched_job_list_empty(sched));
> 
>   drm_sched_entity_fini(entity);
>   drm_sched_fini(drm_sched);
> 
>   /* Destroy workqueue after scheduler tear down, otherwise it might still
>   * be in use.
>   */
>   if (sched->wq)
>   destroy_workqueue(sched->wq);
> }
> 
> 
> We see that it
>     1. stops accepting jobs from userspace (not visible here)
>     2. waits until all hardware fences in this ring are signaled
>     3. only then tears down drm_sched

I cannot do a very deep dive into nouveau at the moment. I see fence 
itself is already freed with kfree_rcu so that's good. What is reachable 
via the timeline name callback:

	struct nouveau_fence *fence = to_nouveau_fence(f);
	struct nouveau_fence_chan *fctx = nouveau_fctx(fence);

	return !fctx->dead ? fctx->name : "dead channel";

Fence is presumably the fence so channel. Chagning to kfree_rcu in 
nouveau_fence_context_put() there might be enough for that one.

For the scheduler (nouveau_sched_destroy()) the same, kfree_rcu.

That makes scheduler timeline name vfunc safe:

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;

sched is then RCU protected. sched->name is already static so not a concern.

As you say nouveau_sched_fini() only tears down the scheduler after 
fences have been signaled it seems adding two new kfree_rcu make is safe.

Regards,

Tvrtko

Re: [PATCH v4 1/3] drm/sched: cache the timeline name to fix a use-after-free

[Tvrtko Ursulin]

On 07/09/2026 11:28, Tvrtko Ursulin wrote:
> 
> On 07/09/2026 10:42, Philipp Stanner wrote:
>> On Mon, 2026-09-07 at 10:15 +0100, Tvrtko Ursulin wrote:
>>>
>>>
>>> On 04/09/2026 20:06, Philipp Stanner wrote:
>>>
>>> 8><
>>>
>>>> If you can think of a stupid and simple solution, shoot. The only thing
>>>> I can think of is moving the string into the dma_fence, as a hard copy
>>>> :)
>>>>
>>>>
>>>> In the mean time, my proposal is to keep aiming for removing
>>>> sched_fence->ops->release and fixing pvr and amdgpu.
>>>
>>> Fixing the drivers sounds like an obvious thing to try indeed. Along the
>>> same lines as it was done for xe and panthor. It is an already
>>> established and well understood approach so shouldn't be controversial.
>>> After that we can discuss in leisurely pace if something better is
>>> possible in the scheduler core.
>>>
>>> I understand its amdxdna, nouveau, and msm. Was it attempted so far? Is
>>> it significantly more complicated than it was for panthor and xe?
>>
>> How did the others fix that?
> 
> Combination of kfree_rcu, synchronize_rcu and storing the name in an 
> object protected by those:
> 
> 6bd90e700b42 ("drm/xe: Make dma-fences compliant with the safe access 
> rules")
> 299bc6d50b1b ("drm/xe/guc: Keep scheduler timeline name alive")
> efe24898485c ("drm/panthor: fix for dma-fence safe access rules")
> 
> Not too complicated on the overall. Simply ensure RCU grace period 
> between signaling the hw fence and freeing the ops, scheduler, name, all 
> that it is in the externally accessible dereference chain.
> 
>> If we look at nouveau:
>>
>> static void
>> nouveau_sched_fini(struct nouveau_sched *sched)
>> {
>>   struct drm_gpu_scheduler *drm_sched = &sched->base;
>>   struct drm_sched_entity *entity = &sched->entity;
>>
>>   wait_event(sched->job.wq, nouveau_sched_job_list_empty(sched));
>>
>>   drm_sched_entity_fini(entity);
>>   drm_sched_fini(drm_sched);
>>
>>   /* Destroy workqueue after scheduler tear down, otherwise it might 
>> still
>>   * be in use.
>>   */
>>   if (sched->wq)
>>   destroy_workqueue(sched->wq);
>> }
>>
>>
>> We see that it
>>     1. stops accepting jobs from userspace (not visible here)
>>     2. waits until all hardware fences in this ring are signaled
>>     3. only then tears down drm_sched
> 
> I cannot do a very deep dive into nouveau at the moment. I see fence 
> itself is already freed with kfree_rcu so that's good. What is reachable 
> via the timeline name callback:
> 
>      struct nouveau_fence *fence = to_nouveau_fence(f);
>      struct nouveau_fence_chan *fctx = nouveau_fctx(fence);
> 
>      return !fctx->dead ? fctx->name : "dead channel";
> 
> Fence is presumably the fence so channel. Chagning to kfree_rcu in 
> nouveau_fence_context_put() there might be enough for that one.
> 
> For the scheduler (nouveau_sched_destroy()) the same, kfree_rcu.
> 
> That makes scheduler timeline name vfunc safe:
> 
> 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;
> 
> sched is then RCU protected. sched->name is already static so not a 
> concern.
> 
> As you say nouveau_sched_fini() only tears down the scheduler after 
> fences have been signaled it seems adding two new kfree_rcu make is safe.

P.S. Idea on how to test it from userspace:

https://patchwork.freedesktop.org/patch/642709/?series=146211&rev=2

But as nouveau does not export via sync_file you would need to adapt to 
export sync_file from syncobj.

Regards,

Tvrtko

Re: [PATCH v4 1/3] drm/sched: cache the timeline name to fix a use-after-free

[Philipp Stanner]

On Mon, 2026-09-07 at 11:28 +0100, Tvrtko Ursulin wrote:
> > 

[…]

> > How did the others fix that?
> 
> Combination of kfree_rcu, synchronize_rcu and storing the name in an 
> object protected by those:

[…]

> For the scheduler (nouveau_sched_destroy()) the same, kfree_rcu.
> 
> That makes scheduler timeline name vfunc safe:
> 
> 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;
> 
> sched is then RCU protected. sched->name is already static so not a concern.
> 
> As you say nouveau_sched_fini() only tears down the scheduler after 
> fences have been signaled it seems adding two new kfree_rcu make is safe.


I don't see how any RCU mechanism would make anything here safe.

As long as ops->release is implemented, ops will never be set to NULL,
(with or without RCU) – so everyone who holds a reference to finished-
fence can still run into drm_sched_fence_get_timeline_name() and cause
UAF on the sched pointer *and* the name pointer.

Moreover, all of this falls apart should the driver unload.

So I maintain the position that we only get it right by having the
signaled-bit be the decoupling point.

Or am I missing something?


P.

Re: [PATCH v4 1/3] drm/sched: cache the timeline name to fix a use-after-free

[Tvrtko Ursulin]

On 07/09/2026 11:47, Philipp Stanner wrote:
> On Mon, 2026-09-07 at 11:28 +0100, Tvrtko Ursulin wrote:
>>>
> 
> […]
> 
>>> How did the others fix that?
>>
>> Combination of kfree_rcu, synchronize_rcu and storing the name in an
>> object protected by those:
> 
> […]
> 
>> For the scheduler (nouveau_sched_destroy()) the same, kfree_rcu.
>>
>> That makes scheduler timeline name vfunc safe:
>>
>> 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;
>>
>> sched is then RCU protected. sched->name is already static so not a concern.
>>
>> As you say nouveau_sched_fini() only tears down the scheduler after
>> fences have been signaled it seems adding two new kfree_rcu make is safe.
> 
> 
> I don't see how any RCU mechanism would make anything here safe.
> 
> As long as ops->release is implemented, ops will never be set to NULL,
> (with or without RCU) – so everyone who holds a reference to finished-
> fence can still run into drm_sched_fence_get_timeline_name() and cause
> UAF on the sched pointer *and* the name pointer.
> 
> Moreover, all of this falls apart should the driver unload.
> 
> So I maintain the position that we only get it right by having the
> signaled-bit be the decoupling point.
> 
> Or am I missing something?

The driver fixes you asked about and I listed work(ed) in the context of 
506aa8b02a8d ("dma-fence: Add safe access helpers and document the 
rules"). In that "world" it would have been safe. Did 035219a760ed 
("dma-buf: dma-fence: Fix potential NULL pointer dereference") break 
those fixes a bit?

I can try my IGT and see..

Regards,

Tvrtko

Re: [PATCH v4 1/3] drm/sched: cache the timeline name to fix a use-after-free

[Philipp Stanner]

On Mon, 2026-09-07 at 12:06 +0100, Tvrtko Ursulin wrote:
> On 07/09/2026 11:47, Philipp Stanner wrote:

[…]

> > 
> > So I maintain the position that we only get it right by having the
> > signaled-bit be the decoupling point.
> > 
> > Or am I missing something?
> 
> The driver fixes you asked about and I listed work(ed) in the context of 
> 506aa8b02a8d ("dma-fence: Add safe access helpers and document the 
> rules"). In that "world" it would have been safe. Did 035219a760ed 
> ("dma-buf: dma-fence: Fix potential NULL pointer dereference") break 
> those fixes a bit?

I think we all agree that 035219a760ed should not have been implemented
in that way because it does not work for drivers that provide a ops-
>release / ops->wait.

So I think the only thing we can do right now is add the signaled-check
back (like Christian suggested) and ensure correct memory ordering –
since we also cannot use the spinlock consistently, as that can still
be extern…


P.

Re: [PATCH v4 1/3] drm/sched: cache the timeline name to fix a use-after-free

[Christian König]

On 9/7/26 13:15, Philipp Stanner wrote:
> On Mon, 2026-09-07 at 12:06 +0100, Tvrtko Ursulin wrote:
>> On 07/09/2026 11:47, Philipp Stanner wrote:
> 
> […]
> 
>>>
>>> So I maintain the position that we only get it right by having the
>>> signaled-bit be the decoupling point.
>>>
>>> Or am I missing something?
>>
>> The driver fixes you asked about and I listed work(ed) in the context of 
>> 506aa8b02a8d ("dma-fence: Add safe access helpers and document the 
>> rules"). In that "world" it would have been safe. Did 035219a760ed 
>> ("dma-buf: dma-fence: Fix potential NULL pointer dereference") break 
>> those fixes a bit?
> 
> I think we all agree that 035219a760ed should not have been implemented
> in that way because it does not work for drivers that provide a ops-
>> release / ops->wait.
> 
> So I think the only thing we can do right now is add the signaled-check
> back (like Christian suggested) and ensure correct memory ordering –
> since we also cannot use the spinlock consistently, as that can still
> be extern…

I think the memory ordering isn't really a problem.

See if the ops pointer or the signaled bit is loaded first doesn't matter if you check both.

You only need to make sure that the ops pointer is loaded once cause that one is used multiple times, but that is already the case by using rcu_dereference().

Or what exactly is your concern?

Thanks,
Christian.

> 
> 
> P.

Re: [PATCH v4 1/3] drm/sched: cache the timeline name to fix a use-after-free

[Philipp Stanner]

On Mon, 2026-09-07 at 14:59 +0200, Christian König wrote:
> I think the memory ordering isn't really a problem.
> 
> See if the ops pointer or the signaled bit is loaded first doesn't
> matter if you check both.
> 
> You only need to make sure that the ops pointer is loaded once cause
> that one is used multiple times, but that is already the case by
> using rcu_dereference().

That.. sounds correct.

Although I still don't get why we then can't use the signaled state
everywhere instead of the ops pointer. That would be simpler.


Anyways.
Maybe Jonghyuk can give your patch a test run and then we could use it
as a hot-fix to backport and discuss the wider future of dma-fence
separately?


P.

Re: [PATCH v4 1/3] drm/sched: cache the timeline name to fix a use-after-free

[Christian König]

On 9/7/26 15:38, Philipp Stanner wrote:
> On Mon, 2026-09-07 at 14:59 +0200, Christian König wrote:
>> I think the memory ordering isn't really a problem.
>>
>> See if the ops pointer or the signaled bit is loaded first doesn't
>> matter if you check both.
>>
>> You only need to make sure that the ops pointer is loaded once cause
>> that one is used multiple times, but that is already the case by
>> using rcu_dereference().
> 
> That.. sounds correct.
> 
> Although I still don't get why we then can't use the signaled state
> everywhere instead of the ops pointer. That would be simpler.

Yeah I have considered that as well.

But I wanted a) to let trace_dma_fence_signaled() be able to trace timeline and driver name for the last time and b) not keep an invalid ops pointer around.

Setting ops to NULL caused some trouble but I think we have solved most of that now.

> Anyways.
> Maybe Jonghyuk can give your patch a test run and then we could use it
> as a hot-fix to backport and discuss the wider future of dma-fence
> separately?

Completely agree.

Regards,
Christian.

> 
> 
> P.

Re: [PATCH v4 1/3] drm/sched: cache the timeline name to fix a use-after-free

[Jonghyuk Kim(MalHyuk)]

On 07/09/2026 17:21, Christian König wrote:
>> Maybe Jonghyuk can give your patch a test run and then we could use
>> it as a hot-fix to backport
> 
> Completely agree.

Ran 0001 on v7.3-rc1-99-g89a312991dc6 with the KUnit regression test from my
v4 3/3 (mock scheduler, KASAN, no hardware). Without it the test fails with

  BUG: KASAN: slab-use-after-free in drm_sched_fence_get_timeline_name+0x9c/0xb0

and with it applied it passes. Reverted and re-applied twice, same both times.

Tested-by: Jonghyuk Kim(MalHyuk) <malhyuk97@gmail.com>

Two things it doesn't cover: it's x86 only, so nothing about the load ordering
you discussed; and only the signaled case - for a fence exported before it
signals, get_timeline_name() is still reached and reads fence->sched->name.
I haven't tried to build that case.

Could you add a Reported-by for me when you post it? I'm happy to drop my
v4 1/3 in favour of this, and can respin the KUnit test standalone so the
fix lands with a regression test.

Thanks,
Jonghyuk

Re: [PATCH v4 1/3] drm/sched: cache the timeline name to fix a use-after-free

[Philipp Stanner]

On Tue, 2026-09-08 at 19:49 +0900, Jonghyuk Kim(MalHyuk) wrote:
> Tested-by: Jonghyuk Kim(MalHyuk) <malhyuk97@gmail.com>
> 
> Two things it doesn't cover: it's x86 only, so nothing about the load ordering
> you discussed;

Christian and I think that it shouldn't be an issue anymore. Both
values are loaded and the ops pointer cannot become invalid until an
RCU grace period has passed. Similarly, sched must not be cleaned up
before that.


>  and only the signaled case - for a fence exported before it
> signals, get_timeline_name() is still reached and reads fence->sched->name.

Is this an issue? A fence can only be exported if the scheduler exists.

The hard rule with dma_fence is that all drivers must signal all of
them before they tear down the scheduler and clean up driver resources.
This then does the decoupling.

I think that rule is really the only chance we have to get things
right.

> I haven't tried to build that case.
> 
> Could you add a Reported-by for me when you post it? I'm happy to drop my
> v4 1/3 in favour of this, and can respin the KUnit test standalone so the
> fix lands with a regression test.

+1
I think since it's @Christian's patch he'll take care of it


Thanks
P.

Re: [PATCH v4 1/3] drm/sched: cache the timeline name to fix a use-after-free

[Jonghyuk Kim(MalHyuk)]

On 08/09/2026 13:07, Philipp Stanner wrote:
> Is this an issue? A fence can only be exported if the scheduler exists.
> The hard rule with dma_fence is that all drivers must signal all of
> them before they tear down the scheduler

Agreed for the bug at hand - that fence is signaled, so 0001 covers it.

My point was narrower: nothing enforces the rule. drm_sched_fini() only does

  if (!list_empty(&sched->pending_list))
          dev_warn(sched->dev, "Tearing down scheduler while jobs are pending!\n");

and the one path that would drain the list, drm_sched_cancel_remaining_jobs(),
needs ops->cancel_job, which no driver in current mainline implements -
the only user is the mock scheduler in the KUnit tests. So a driver that
gets it wrong gets a warning, not a stopped teardown. Not an argument
against the hot-fix.

Thanks,
Jonghyuk

Re: [PATCH v4 1/3] drm/sched: cache the timeline name to fix a use-after-free

[Philipp Stanner]

On Wed, 2026-09-09 at 09:37 +0900, Jonghyuk Kim(MalHyuk) wrote:
> On 08/09/2026 13:07, Philipp Stanner wrote:
> > Is this an issue? A fence can only be exported if the scheduler exists.
> > The hard rule with dma_fence is that all drivers must signal all of
> > them before they tear down the scheduler
> 
> Agreed for the bug at hand - that fence is signaled, so 0001 covers it.
> 
> My point was narrower: nothing enforces the rule. drm_sched_fini() only does
> 
>   if (!list_empty(&sched->pending_list))
>           dev_warn(sched->dev, "Tearing down scheduler while jobs are pending!\n");
> 
> and the one path that would drain the list, drm_sched_cancel_remaining_jobs(),
> needs ops->cancel_job, which no driver in current mainline implements -
> the only user is the mock scheduler in the KUnit tests. So a driver that
> gets it wrong gets a warning, not a stopped teardown. Not an argument
> against the hot-fix.

True. The cancel_job() cb is currently the recommended solution
(although there was disagreement back then) that Tvrtko and I came up
with a while ago. The issue was that drm_sched was designed with no
idiomatic solution for handling remaining jobs in sched->pending_list
on teardown, which is why all drivers presumably have different
solutions. cancel_job() was an attempt at providing an idiomatic
solution.

It's afaik currently being used by Asahi downstream and was used in
Nouveau, but Nouveau doesn't need it / cannot use it for other reasons
that have to do with page table cleanup AFAIR. So Nouveau covers it
with a waitqueue. We could add it to Nouveau again, but then it would
never be called because the waitqueue comes first and needs to stay…

So should you see a driver that could make good use of it, I would
appreciate if you'd try to add it :)

Re: [PATCH v4 1/3] drm/sched: cache the timeline name to fix a use-after-free

[Tvrtko Ursulin]

On 07/09/2026 12:06, Tvrtko Ursulin wrote:
> 
> On 07/09/2026 11:47, Philipp Stanner wrote:
>> On Mon, 2026-09-07 at 11:28 +0100, Tvrtko Ursulin wrote:
>>>>
>>
>> […]
>>
>>>> How did the others fix that?
>>>
>>> Combination of kfree_rcu, synchronize_rcu and storing the name in an
>>> object protected by those:
>>
>> […]
>>
>>> For the scheduler (nouveau_sched_destroy()) the same, kfree_rcu.
>>>
>>> That makes scheduler timeline name vfunc safe:
>>>
>>> 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;
>>>
>>> sched is then RCU protected. sched->name is already static so not a 
>>> concern.
>>>
>>> As you say nouveau_sched_fini() only tears down the scheduler after
>>> fences have been signaled it seems adding two new kfree_rcu make is 
>>> safe.
>>
>>
>> I don't see how any RCU mechanism would make anything here safe.
>>
>> As long as ops->release is implemented, ops will never be set to NULL,
>> (with or without RCU) – so everyone who holds a reference to finished-
>> fence can still run into drm_sched_fence_get_timeline_name() and cause
>> UAF on the sched pointer *and* the name pointer.
>>
>> Moreover, all of this falls apart should the driver unload.
>>
>> So I maintain the position that we only get it right by having the
>> signaled-bit be the decoupling point.
>>
>> Or am I missing something?
> 
> The driver fixes you asked about and I listed work(ed) in the context of 
> 506aa8b02a8d ("dma-fence: Add safe access helpers and document the 
> rules"). In that "world" it would have been safe. Did 035219a760ed 
> ("dma-buf: dma-fence: Fix potential NULL pointer dereference") break 
> those fixes a bit?
> 
> I can try my IGT and see..

With RCU frees in xe it is harder to hit it reliably for KASAN to 
notice. Guess I would need to have a way to flush the RCU callbacks from 
IGT but I did not bother with that, it seemed easier to check the 
returned name. Since it is not returning "detached-driver" / 
"detached-timeline" post signalling that proves things are indeed broken:

$ sudo tests/xe_sync_file
IGT-Version: 2.5-ge37a85b91 (x86_64) (Linux: 7.3.0-rc1+ x86_64)
Using IGT_SRANDOM=1788784104 for randomisation
Opened device: /dev/dri/card0
Starting subtest: sync_file_race
[2178.517756] (xe_sync_file:10970) CRITICAL: Test assertion failure 
function test_race, file ../tests/intel/xe_sync_file.c:130:
[2178.517790] (xe_sync_file:10970) CRITICAL: Failed assertion: 
!strcmp(driver_name, "detached-driver")
Stack trace:
   #0 ../lib/igt_core.c:2089 __igt_fail_assert()
   #1 ../tests/intel/xe_sync_file.c:155 __igt_unique____real_main136()
   #2 ../tests/intel/xe_sync_file.c:136 main()
   #3 ../sysdeps/nptl/libc_start_call_main.h:83 __libc_start_call_main()
   #4 ../csu/libc-start.c:128 __libc_start_main@@GLIBC_2.34()
   #5 [_start+0x25]
Subtest sync_file_race failed.
**** DEBUG ****
[2177.516393] (xe_sync_file:10970) DEBUG: 'drm_sched'/'rcs16' = 1
[2178.517745] (xe_sync_file:10970) DEBUG: 'drm_sched'/'rcs16' = 1
[2178.517756] (xe_sync_file:10970) CRITICAL: Test assertion failure 
function test_race, file ../tests/intel/xe_sync_file.c:130:
[2178.517790] (xe_sync_file:10970) CRITICAL: Failed assertion: 
!strcmp(driver_name, "detached-driver")
[2178.518762] (xe_sync_file:10970) igt_core-INFO: Stack trace:
[2178.523313] (xe_sync_file:10970) igt_core-INFO:   #0 
../lib/igt_core.c:2089 __igt_fail_assert()
[2178.523428] (xe_sync_file:10970) igt_core-INFO:   #1 
../tests/intel/xe_sync_file.c:155 __igt_unique____real_main136()
[2178.523436] (xe_sync_file:10970) igt_core-INFO:   #2 
../tests/intel/xe_sync_file.c:136 main()
[2178.564635] (xe_sync_file:10970) igt_core-INFO:   #3 
../sysdeps/nptl/libc_start_call_main.h:83 __libc_start_call_main()
[2178.564690] (xe_sync_file:10970) igt_core-INFO:   #4 
../csu/libc-start.c:128 __libc_start_main@@GLIBC_2.34()
[2178.564892] (xe_sync_file:10970) igt_core-INFO:   #5 [_start+0x25]
****  END  ****
Subtest sync_file_race: FAIL (1.054s)

I'll copy you on the updated IGT for reference.

Regards,

Tvrtko

Re: [PATCH v4 1/3] drm/sched: cache the timeline name to fix a use-after-free

[Tvrtko Ursulin]

On 07/09/2026 13:28, Tvrtko Ursulin wrote:
> 
> On 07/09/2026 12:06, Tvrtko Ursulin wrote:
>>
>> On 07/09/2026 11:47, Philipp Stanner wrote:
>>> On Mon, 2026-09-07 at 11:28 +0100, Tvrtko Ursulin wrote:
>>>>>
>>>
>>> […]
>>>
>>>>> How did the others fix that?
>>>>
>>>> Combination of kfree_rcu, synchronize_rcu and storing the name in an
>>>> object protected by those:
>>>
>>> […]
>>>
>>>> For the scheduler (nouveau_sched_destroy()) the same, kfree_rcu.
>>>>
>>>> That makes scheduler timeline name vfunc safe:
>>>>
>>>> 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;
>>>>
>>>> sched is then RCU protected. sched->name is already static so not a 
>>>> concern.
>>>>
>>>> As you say nouveau_sched_fini() only tears down the scheduler after
>>>> fences have been signaled it seems adding two new kfree_rcu make is 
>>>> safe.
>>>
>>>
>>> I don't see how any RCU mechanism would make anything here safe.
>>>
>>> As long as ops->release is implemented, ops will never be set to NULL,
>>> (with or without RCU) – so everyone who holds a reference to finished-
>>> fence can still run into drm_sched_fence_get_timeline_name() and cause
>>> UAF on the sched pointer *and* the name pointer.
>>>
>>> Moreover, all of this falls apart should the driver unload.
>>>
>>> So I maintain the position that we only get it right by having the
>>> signaled-bit be the decoupling point.
>>>
>>> Or am I missing something?
>>
>> The driver fixes you asked about and I listed work(ed) in the context 
>> of 506aa8b02a8d ("dma-fence: Add safe access helpers and document the 
>> rules"). In that "world" it would have been safe. Did 035219a760ed 
>> ("dma-buf: dma-fence: Fix potential NULL pointer dereference") break 
>> those fixes a bit?
>>
>> I can try my IGT and see..
> 
> With RCU frees in xe it is harder to hit it reliably for KASAN to 
> notice. Guess I would need to have a way to flush the RCU callbacks from 
> IGT but I did not bother with that, it seemed easier to check the 
> returned name. Since it is not returning "detached-driver" / "detached- 
> timeline" post signalling that proves things are indeed broken:
> 
> $ sudo tests/xe_sync_file
> IGT-Version: 2.5-ge37a85b91 (x86_64) (Linux: 7.3.0-rc1+ x86_64)
> Using IGT_SRANDOM=1788784104 for randomisation
> Opened device: /dev/dri/card0
> Starting subtest: sync_file_race
> [2178.517756] (xe_sync_file:10970) CRITICAL: Test assertion failure 
> function test_race, file ../tests/intel/xe_sync_file.c:130:
> [2178.517790] (xe_sync_file:10970) CRITICAL: Failed assertion: ! 
> strcmp(driver_name, "detached-driver")
> Stack trace:
>    #0 ../lib/igt_core.c:2089 __igt_fail_assert()
>    #1 ../tests/intel/xe_sync_file.c:155 __igt_unique____real_main136()
>    #2 ../tests/intel/xe_sync_file.c:136 main()
>    #3 ../sysdeps/nptl/libc_start_call_main.h:83 __libc_start_call_main()
>    #4 ../csu/libc-start.c:128 __libc_start_main@@GLIBC_2.34()
>    #5 [_start+0x25]
> Subtest sync_file_race failed.
> **** DEBUG ****
> [2177.516393] (xe_sync_file:10970) DEBUG: 'drm_sched'/'rcs16' = 1
> [2178.517745] (xe_sync_file:10970) DEBUG: 'drm_sched'/'rcs16' = 1
> [2178.517756] (xe_sync_file:10970) CRITICAL: Test assertion failure 
> function test_race, file ../tests/intel/xe_sync_file.c:130:
> [2178.517790] (xe_sync_file:10970) CRITICAL: Failed assertion: ! 
> strcmp(driver_name, "detached-driver")
> [2178.518762] (xe_sync_file:10970) igt_core-INFO: Stack trace:
> [2178.523313] (xe_sync_file:10970) igt_core-INFO:   #0 ../lib/ 
> igt_core.c:2089 __igt_fail_assert()
> [2178.523428] (xe_sync_file:10970) igt_core-INFO:   #1 ../tests/intel/ 
> xe_sync_file.c:155 __igt_unique____real_main136()
> [2178.523436] (xe_sync_file:10970) igt_core-INFO:   #2 ../tests/intel/ 
> xe_sync_file.c:136 main()
> [2178.564635] (xe_sync_file:10970) igt_core-INFO:   #3 ../sysdeps/nptl/ 
> libc_start_call_main.h:83 __libc_start_call_main()
> [2178.564690] (xe_sync_file:10970) igt_core-INFO:   #4 ../csu/libc- 
> start.c:128 __libc_start_main@@GLIBC_2.34()
> [2178.564892] (xe_sync_file:10970) igt_core-INFO:   #5 [_start+0x25]
> ****  END  ****
> Subtest sync_file_race: FAIL (1.054s)
> 
> I'll copy you on the updated IGT for reference.

For reference Intel's CI managed to catch the UAF using the test I 
re-posted yesterday:

https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15796/shard-bmg-9/igt@xe_sync_file@sync_file_race.html

<6> [107.688696] [IGT] xe_sync_file: executing
<6> [107.711053] [IGT] xe_sync_file: starting subtest sync_file_race
<4> [108.719407] Oops: general protection fault, probably for 
non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] SMP NOPTI
<4> [108.730119] CPU: 11 UID: 0 PID: 4227 Comm: xe_sync_file Tainted: G 
S   U              7.3.0-rc2-lgci-xe-xe-5698-547f981c369d4b8ad-debug+ #1 
PREEMPT(lazy)
<4> [108.743915] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER
<4> [108.748699] Hardware name: ASUS System Product Name/PRIME Z790-P 
WIFI, BIOS 1645 03/15/2024
<4> [108.757038] RIP: 0010:strnlen+0x17/0x50
<4> [108.760873] Code: 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 
90 90 90 48 8d 14 37 48 89 f8 48 85 f6 75 0b eb 2d 48 83 c0 01 48 39 c2 
74 13 <80> 38 00 75 f2 48 29 f8 31 d2 31 f6 31 ff c3 cc cc cc cc 48 89 d0
<4> [108.779603] RSP: 0018:ffffc9000414fcc8 EFLAGS: 00010202
<4> [108.784827] RAX: 6b6b6b6b6b6b6b6b RBX: 0000000000000050 RCX: 
0000000000000000
<4> [108.791954] RDX: 6b6b6b6b6b6b6b8b RSI: 0000000000000020 RDI: 
6b6b6b6b6b6b6b6b
<4> [108.799079] RBP: ffffc9000414fd90 R08: 0000000000000000 R09: 
0000000000000000
<4> [108.806201] R10: 0000000000000000 R11: 0000000000000000 R12: 
ffff8881098231a0
<4> [108.813329] R13: 0000000000000020 R14: ffff88816a833ab8 R15: 
6b6b6b6b6b6b6b6b
<4> [108.820454] FS:  00007de5028bebc0(0000) GS:ffff8888d5fdb000(0000) 
knlGS:0000000000000000
<4> [108.828530] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4> [108.834268] CR2: 00007de5028bc000 CR3: 000000012c9b7001 CR4: 
0000000000f72ef0
<4> [108.841396] PKRU: 55555554
<4> [108.844104] Call Trace:
<4> [108.846554]  <TASK>
<4> [108.848656]  ? sync_file_ioctl+0x1ed/0x750
<4> [108.852754]  ? sync_file_ioctl+0x153/0x750
<4> [108.856850]  __x64_sys_ioctl+0xa5/0x100
<4> [108.860691]  x64_sys_call+0x2b5/0x27e0
<4> [108.864439]  do_syscall_64+0xea/0x670
<4> [108.868101]  ? do_syscall_64+0x224/0x670
<4> [108.872024]  ? trace_hardirqs_on_prepare+0xcb/0xf0
<4> [108.876812]  ? do_syscall_64+0x224/0x670
<4> [108.880736]  ? trace_hardirqs_on_prepare+0xcb/0xf0
<4> [108.885522]  ? trace_hardirqs_off_finish+0xc7/0xe0
<4> [108.890307]  ? do_syscall_64+0x58/0x670
<4> [108.894143]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
<4> [108.899190] RIP: 0033:0x7de504724f1d
<4> [108.902764] Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 
c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 
0f 05 <89> c2 3d 00 f0 ff ff 77 1a 48 8b 45 c8 64 48 2b 04 25 28 00 00 00
<4> [108.921497] RSP: 002b:00007ffdc9fd5e50 EFLAGS: 00000246 ORIG_RAX: 
0000000000000010
<4> [108.929059] RAX: ffffffffffffffda RBX: 00007ffdc9fd5fd8 RCX: 
00007de504724f1d
<4> [108.936182] RDX: 00007ffdc9fd5ee0 RSI: 00000000c0383e04 RDI: 
0000000000000006
<4> [108.943310] RBP: 00007ffdc9fd5ea0 R08: 0000000000000000 R09: 
0000000000000000
<4> [108.950435] R10: 00007ffdc9fd5f60 R11: 0000000000000246 R12: 
00007ffdc9fd5ee0
<4> [108.957558] R13: 00000000c0383e04 R14: 0000000000000006 R15: 
0000000000000005
<4> [108.964686]  </TASK>


Regards,

Tvrtko

Re: [PATCH v4 1/3] drm/sched: cache the timeline name to fix a use-after-free

[Alessio Belle]

Hi,

On Mon, 2026-09-07 at 11:42 +0200, Philipp Stanner wrote:
> On Mon, 2026-09-07 at 10:15 +0100, Tvrtko Ursulin wrote:
> > 
> > 
> > On 04/09/2026 20:06, Philipp Stanner wrote:
> > 
> > 8><
> > 
> > > If you can think of a stupid and simple solution, shoot. The only thing
> > > I can think of is moving the string into the dma_fence, as a hard copy
> > > :)
> > > 
> > > 
> > > In the mean time, my proposal is to keep aiming for removing
> > > sched_fence->ops->release and fixing pvr and amdgpu.
> > 
> > Fixing the drivers sounds like an obvious thing to try indeed. Along the 
> > same lines as it was done for xe and panthor. It is an already 
> > established and well understood approach so shouldn't be controversial. 
> > After that we can discuss in leisurely pace if something better is 
> > possible in the scheduler core.
> > 
> > I understand its amdxdna, nouveau, and msm. Was it attempted so far? Is 
> > it significantly more complicated than it was for panthor and xe?
> 
> How did the others fix that?
> 
> If we look at nouveau:
> 
> static void
> nouveau_sched_fini(struct nouveau_sched *sched)
> {
>  struct drm_gpu_scheduler *drm_sched = &sched->base;
>  struct drm_sched_entity *entity = &sched->entity;
> 
>  wait_event(sched->job.wq, nouveau_sched_job_list_empty(sched));
> 
>  drm_sched_entity_fini(entity);
>  drm_sched_fini(drm_sched);
> 
>  /* Destroy workqueue after scheduler tear down, otherwise it might still
>  * be in use.
>  */
>  if (sched->wq)
>  destroy_workqueue(sched->wq);
> }
> 
> 
> We see that it
>    1. stops accepting jobs from userspace (not visible here)
>    2. waits until all hardware fences in this ring are signaled
>    3. only then tears down drm_sched
> 
> Then nouveau might unload or free up resources.
> 
> The nasty thing is that I don't see how nouveau misbehaves here and how
> the stuff might be fixed.
> 
> The problem is that the sched_fence implements ops->release, so the
> check doesn't take effect.
> 
> Moreover, even if we did remove ops->release in drm_sched, it would
> still be a race: a driver's contract is the hardware_fence, the rule
> being that you have to signal those. So after signaling the last
> hardware_fence, you could actually start releasing resources, but it
> might be that finished_fences are still in-flight and are unsignaled.
> 
> So we have some sort of fence -> fence race here, too.
> 
> > 
> > As for regarding the 035219a760ed ("dma-buf: dma-fence: Fix potential
> > NULL pointer dereference") sub-thread - I did not manage to penetrate
> > the consensus there - whether it was established that it needs adding
> > the is signaled check back (with additional memory barriers, like v1 of 
> > that patch) or not? Regardless of fixing the drivers or what?
> 
> 
> As far as my understanding goes this is the only way to get this right
> for everyone, i.e. also users who implement ops->release(). Then at
> least the driver could unload after signalling all its fences (with the
> exception of those who have a shared spinlock maybe).
> 
> 
> However, I suppose then we would then have two mechanisms, one dancing
> with RCU around the ops pointer, the other checking whether the fence
> is signaled, presumably with manual ordering through barriers.
> 
> My first guess would be that maybe we should only rely on the signaled-
> state and leave the ops-pointer untouched? This should also work for
> pvr, notably.

It seems in the meantime the discussion moved towards fixing the common code, at
least in the short term (correct?), but pointing out anyway that if needed,
having a similar fix on the powervr side would also be fine for us especially
for backporting purposes.

We are looking at alternatives to avoid accessing sched_fence->sched->ops, but
can't tell yet if it can be done without loss of functionality and/or
performance and how safe it is to backport.

Thanks,
Alessio

> 
> 
> P.

Re: [PATCH v4 1/3] drm/sched: cache the timeline name to fix a use-after-free

[Christian König]

[-- Attachment #1: Type: text/plain, Size: 4948 bytes --]

On 9/4/26 21:06, Philipp Stanner wrote:
> On Fri, 2026-09-04 at 14:49 +0200, Christian König wrote:
>> On 9/4/26 10:31, Philipp Stanner wrote:
>>> On Fri, 2026-09-04 at 10:20 +0200, Christian König wrote:
>>>>
> 
> […]
> 
>>>>
>>>> That sounds like a bad idea as well.
>>>>
>>>> Dropping the fence->ops is to detach the fence from the module
>>>> which originally issued it and not solve lifetime problems
>>>> between the scheduler and the driver.
>>>
>>> It can be used to solve that problem though, can it not?
>>
>> Yes, but I think forcing dma_fence implementations to drop their
>> release callback to fix lifetime problems with the driver and
>> timeline name functions is a bad idea.
> 
> The issue we're facing is not so much related with life times, is it?
> 
> Even if the driver correctly tears down the scheduler (i.e., signal all
> hardware fences), this problem still exists.

Well no, before patch "035219a760ed dma-buf: dma-fence: Fix potential NULL pointer dereference" everything worked correctly as long as the driver waited for an RCU grace period before tearing down the scheduler.

After this patch we now messed up the lifetime for the scheduler fence get_timeline_name and get_driver_name callbacks.
>>
>> We should keep this fix simple and focused so that we can easily backport it.
> 
> My hope would be that the dma_fence backend solution can be used that
> *already exists*. That could then both be simple and maintainable.
> 
> 
> Correct me if I'm wrong, but it seems we have not found an alternative
> solution that can work yet?

I think we did. The problem was introduced with patch 035219a760ed and I think we should fix it there as well.

We just need to start checking for both the ops and signaled status in the dma_fence framework.
>>
>>>>
>>>> I think we should rather re-consider patch
>>>> 035219a760edb35ae9a9e96beba7f122e26a997b ("dma-buf: dma-fence:
>>>> Fix potential NULL pointer dereference"):
>>>>
>>>> Here we changed the check in dma_fence_driver_name() and
>>>> dma_fence_timeline_name():
>>>>
>>>> @@ -1167,7 +1167,7 @@ const char __rcu *dma_fence_driver_name(struct dma_fence *fence)
>>>>  
>>>>         /* RCU protection is required for safe access to returned string */
>>>>         ops = rcu_dereference(fence->ops);
>>>> -       if (!dma_fence_test_signaled_flag(fence))
>>>> +       if (ops)
>>>>                 return (const char __rcu *)ops->get_driver_name(fence);
>>>>         else
>>>>                 return (const char __rcu *)"detached-driver";
>>>>
>>>> The problem is that we didn't considered that there a fence
>>>> implementations which still have a release or wait callbacks but
>>>> rely on not needing to return a string for a signaled fence.
>>>>
>>>
>>> Could we move the signaled check to amdgpu and pvr?
>>
>> Yes we could. I also considered that. But I would rather like to see
>> it handled in the common dma_fence code.
>>
>> If I remember correctly either Tvrko, you or somebody else was in
>> favor of doing "if (!dma_fence_test_signaled_flag(fence) && ops)"
>> here but I though that this was unnecessary and we would rather
>> remove the release callbacks. Maybe I was wrong with that.
> 
> I hope that wasn't me because that again looks very racy.

Why? Tvrtko added the RCU protection for that.
> I think that there is no way around using the spinlock. As I have
> pointed out many times, the fact that the signaled-bit is set with lock
> protection and read without it is fundamentally broken :(

As far as I can see the RCU approach works just fine, the problem is only that we dropped the check for the signaled bit from the common framework and didn't considered that scheduler fence and a few other weren't changed to not have a release callback yet.

>>> IOW, we keep the solution presented here (removing ops->release for
>>> finished-fence) and the few drivers that check whether a fence is
>>> their
>>> own first do a locked dma_fence_is_signaled() check?
>>
>> Works for me as well, but as I said I would rather like to keep it
>> simple and stupid for backporting.
> 
> If you can think of a stupid and simple solution, shoot. The only thing
> I can think of is moving the string into the dma_fence, as a hard copy
> :)

See attached. It doesn't fully solve the problem, but it gives us the status again we had after Tvrtko's RCU protection work.
> In the mean time, my proposal is to keep aiming for removing
> sched_fence->ops->release and fixing pvr and amdgpu.

Hui? For amdgpu that is completely irrelevant since that driver only destroys the scheduler on driver unload.

And there we always had the problem that when the module is unloaded we pretty much crash the kernel because the ops pointer is still around.

Regards,
Christian.
> I think that will have to entail a signaled-check. Question would then
> be whether we place it in the driver or the backend.
> 
> 
> P.

[-- Attachment #2: 0001-dma-buf-dma-fence-fix-checking-signaling-bit-for-tim.patch --]
[-- Type: text/x-patch, Size: 2301 bytes --]

From e70aebd9106f695179439273be985e589e63f3dd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Christian=20K=C3=B6nig?= <christian.koenig@amd.com>
Date: Fri, 4 Sep 2026 10:26:13 +0200
Subject: [PATCH 1/2] dma-buf/dma-fence: fix checking signaling bit for
 timeline and driver name
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The patch "dma-buf: dma-fence: Fix potential NULL pointer dereference"
changed the check to test for the ops pointer instead of the signaled
bit to avoid a potential NULL dereference when the ops pointer has been
cleared.

The problem is now that the ops pointer is cleared only when neither the
release nor the wait callback is implemented and this isn't true for a lot
of dma_fence implementations yet. So those implementations lost the RCU
protection after signaling of the returned string resulting in potential
use after free.

Add the signaling check additional to the ops pointer check so that we
have both the protection against NULL dereference as well as the RCU
protection after signaling for the returned string.

Signed-off-by: Christian König <christian.koenig@amd.com>
Fixes: 035219a760ed ("dma-buf: dma-fence: Fix potential NULL pointer dereference")
CC: stable@vger.kernel.org # 7.2+
---
 drivers/dma-buf/dma-fence.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 05090fb0fd5a..e92f9df8d63c 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -1170,7 +1170,7 @@ const char __rcu *dma_fence_driver_name(struct dma_fence *fence)
 
 	/* RCU protection is required for safe access to returned string */
 	ops = rcu_dereference(fence->ops);
-	if (ops)
+	if (!dma_fence_test_signaled_flag(fence) && ops)
 		return (const char __rcu *)ops->get_driver_name(fence);
 	else
 		return (const char __rcu *)"detached-driver";
@@ -1203,7 +1203,7 @@ const char __rcu *dma_fence_timeline_name(struct dma_fence *fence)
 
 	/* RCU protection is required for safe access to returned string */
 	ops = rcu_dereference(fence->ops);
-	if (ops)
+	if (!dma_fence_test_signaled_flag(fence) && ops)
 		return (const char __rcu *)ops->get_timeline_name(fence);
 	else
 		return (const char __rcu *)"signaled-timeline";
-- 
2.43.0


[-- Attachment #3: 0002-drm-sched-document-the-RCU-dependency.patch --]
[-- Type: text/x-patch, Size: 1719 bytes --]

From b93e52501e8920a881227011212920fa84247639 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Christian=20K=C3=B6nig?= <christian.koenig@amd.com>
Date: Mon, 7 Sep 2026 10:59:42 +0200
Subject: [PATCH 2/2] drm/sched: document the RCU dependency
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Tvrkos patches added RCU protection to the returned strings from
get_timeline_name()/get_driver_name() callbacks of the dma_fence
backends.

This fixed use after free problems for a couple of drivers, but we never
documented the consequences for the drm_sched_fence.

Add a few words on the function documentation to note that we need an
RCU grace period between signaling the last scheduler fence and
scheduler teardown.

Signed-off-by: Christian König <christian.koenig@amd.com>
---
 drivers/gpu/drm/scheduler/sched_main.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/scheduler/sched_main.c b/drivers/gpu/drm/scheduler/sched_main.c
index 6cb6f9546493..22103cb07782 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)
 {
-- 
2.43.0

Re: [PATCH v4 1/3] drm/sched: cache the timeline name to fix a use-after-free

[Philipp Stanner]

On Mon, 2026-09-07 at 13:42 +0200, Christian König wrote:
> Well no, before patch "035219a760ed dma-buf: dma-fence: Fix potential
> NULL pointer dereference" everything worked correctly as long as the
> driver waited for an RCU grace period before tearing down the
> scheduler.

035219a760ed literally fixed a race condition for weakly ordered
platforms, so I wouldn't say that "everything worked correctly" :)

> 

[…]

> > 
> > 
> > Correct me if I'm wrong, but it seems we have not found an alternative
> > solution that can work yet?
> 
> I think we did. The problem was introduced with patch 035219a760ed
> and I think we should fix it there as well.
> 
> We just need to start checking for both the ops and signaled status
> in the dma_fence framework.

Agreed, we should address the problem there.

But see my other answer to Tvrtko. I think if the decoupling point is
the signaled bit anyways, we can and should stop setting ops to NULL in
the first place.

Because now we'd have two decoupling points.


> > > > 
> > 
> > I hope that wasn't me because that again looks very racy.
> 
> Why? Tvrtko added the RCU protection for that.

RCU does not address ordering between signaled bit and ops pointer.

> > I think that there is no way around using the spinlock. As I have
> > pointed out many times, the fact that the signaled-bit is set with lock
> > protection and read without it is fundamentally broken :(
> 
> As far as I can see the RCU approach works just fine, the problem is
> only that we dropped the check for the signaled bit from the common
> framework and didn't considered that scheduler fence and a few other
> weren't changed to not have a release callback yet.
> 
> > > > IOW, we keep the solution presented here (removing ops->release for
> > > > finished-fence) and the few drivers that check whether a fence is
> > > > their
> > > > own first do a locked dma_fence_is_signaled() check?
> > > 
> > > Works for me as well, but as I said I would rather like to keep it
> > > simple and stupid for backporting.
> > 
> > If you can think of a stupid and simple solution, shoot. The only thing
> > I can think of is moving the string into the dma_fence, as a hard copy
> > :)
> 
> See attached. It doesn't fully solve the problem, but it gives us the
> status again we had after Tvrtko's RCU protection work.
> 

Patch 0001 seems to reintroduce the race condition. No one guarantees
that the CPU will load the signaled flag before the ops.

P.

Re: [PATCH v4 1/3] drm/sched: cache the timeline name to fix a use-after-free

[Danilo Krummrich]

On Fri Sep 4, 2026 at 10:06 AM CEST, Jonghyuk Kim(MalHyuk) wrote:
> Fixes: 506aa8b02a8d ("dma-fence: Add safe access helpers and document the rules")
> Cc: stable@vger.kernel.org # we don't know since when

How is that? If there's a Fixes: tag it expresses that this commit introduced
the bug, so it should be known exactly since when it is present.

However, I don't think this is the correct Fixes: tag, the bug was present
before. I think it was present all the way back to commit f556cb0caeec
("drm/amd: add scheduler fence implementation (v2)").

It is also not the case that it wasn't a bug before we had per-context
schedulers, it's just that it became much more likely to trigger with
per-context schedulers; nothing prevents the kernel from having a reference
count of a DMA fence after the driver was unbound and hence the
per-device/per-ring scheduler was torn down.

More in general, putting "we don't know since when" for the stable folks is
rough. If neither the author of the patch nor the maintainers of the subsystem
can figure it out, how are the stable folks supposed to?

Re: [PATCH v4 1/3] drm/sched: cache the timeline name to fix a use-after-free

[Philipp Stanner]

On Fri, 2026-09-04 at 11:57 +0200, Danilo Krummrich wrote:
> On Fri Sep 4, 2026 at 10:06 AM CEST, Jonghyuk Kim(MalHyuk) wrote:
> > Fixes: 506aa8b02a8d ("dma-fence: Add safe access helpers and document the rules")
> > Cc: stable@vger.kernel.org # we don't know since when
> 
> How is that?

That is referring to the fact that it only is a reachable bug if the
respective driver exposes a mechanism that runs into
get_timeline_name().

> 
> More in general, putting "we don't know since when" for the stable folks is
> rough. If neither the author of the patch nor the maintainers of the subsystem
> can figure it out, how are the stable folks supposed to?

That's on me, it was a joking phrase by me that Jonghyuk or his LLM
picked up 1:1.

Anyways. So would you suggest backporting a fix as far as possible to
the amd origin commit? That might not be backportable that far, so
stable would still have to figure it out.


P.