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.