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