Re: [PATCH v3 1/2] drm/sched: fix use-after-free of the fence timeline name

[Philipp Stanner]

On Fri, 2026-09-04 at 03:01 +0900, Jonghyuk Kim(MalHyuk) wrote:
> Thanks a lot for the thorough review, and for pulling in the pvr folks.
> 

[…]

> every to_drm_sched_fence() caller. I don't think that is the right trade for a
> fix we want to backport.

Would seem so. But then adding an appropriate TODO seems right. Also an
entry in the scheduler's section in Documentation/gpu/todo.rst

> 
> Christian's point that the finished/scheduled .release callbacks are
> "unproblematic for the problem at hand" matches this: the release callbacks do
> not need to be removed to fix the timeline-name UAF, so keeping them (and thus
> the ops attached, and to_drm_sched_fence() working) is fine.

I think that's only the case because the scheduled-fence is not exposed
to userspace by anyone yet.

But since the entire drm_sched_fence is a public API object, sharing it
with userspace would be legal, although doing so likely makes not much
sense.

> 
> Given that, I'd like to fall back to the minimal caching fix and drop the
> ops/refcount rework entirely:

I guess that's the best thing we can do right now.

> 
> 

[…]

> 
> On the specific points:
> 
>  - get_driver_name(): it returns the literal "drm_sched" and never touches
>    ->sched, so unlike get_timeline_name() it isn't exposed. Only the timeline
>    name needs the fix.

I'm not so sure about that.

The primary reason why the rcu-decoupling was implemented is so that
drivers can unload while there are still consumer fences around.

The problem at hand fundamentally stems from the fact that we have two
fences, hardware_fence (often called "parent") and sched_fence. The
driver only cares about the hardware fence, and then there's a delay
between signalling of the hw_fence and the sched_fence, which then
decouples.

So get_driver_name() could still run into a code-UAF, depending on
where the string literal is stored.

> 

[…]

> 
> Unless someone would prefer to keep ops-detach and fix the two callers instead,

I mean, that *is* the gold-standard solution for the problem at hand,
because it complies with the new ideal for dma_fence usage.

But it's a bit of work probably, since you'd need to figure out
solutions for the problems we discussed. Christian can probably help a
lot with amdgpu, maybe the other folks with pvr.

Up to you whether you have time to try to fix the problem in this
manner. If not, as mentioned above, we should leave an entry in the
TODO list.

> I'll respin as the caching v4 once Tvrtko and the pvr folks have had a chance to
> look as well.

Cool, thx!
btw, replying inline at the corresponding mails with the others' quotes
above is preferable since that helps people catch up context, and
people more easily can spot whether you're addressing them. Not always
possible, but preferable.


P.