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

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

New issues:
- [High] The patch fails to fully fix the Use-After-Free in get_timeline_name() for drivers that dynamically allocate the timeline name (drm/panthor and drm/xe). Caching the pointer merely shifts the UAF to the string's lifetime.

Pre-existing issues:
- [High] amdgpu_sync_same_dev blindly casts any drm_sched_fence to an amdgpu_ring, causing out-of-bounds reads and potential use-after-free for foreign fences.
- [High] pvr_queue_fence_is_native dereferences sched_fence->sched->ops on foreign fences, leading to a Use-After-Free if the foreign scheduler was destroyed.
--

commit 5c48f101c7375d5ec48751f42c79a19d2a8e35b2
Author: Jonghyuk Kim(MalHyuk) <malhyuk97@gmail.com>

drm/sched: cache the timeline name to fix a use-after-free

This commit caches the scheduler's timeline name during fence initialization
to prevent a use-after-free when querying the timeline name of a finished
fence whose scheduler was destroyed. It updates get_timeline_name to use
this cached value instead of dereferencing the scheduler.

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

[Severity: High]
This isn't a bug introduced by this patch, but amdgpu_sync_same_dev blindly
casts any drm_sched_fence to an amdgpu_ring, which can cause out-of-bounds
reads and potential use-after-free for foreign fences.

If a userspace process creates a job on a different DRM driver that uses
drm/scheduler, exports the resulting dma_fence to a sync_file, and passes it
as a dependency to an amdgpu job, can this cast access out-of-bounds memory?

drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c:amdgpu_sync_same_dev() {
    ...
		struct amdgpu_ring *ring;

		ring = container_of(s_fence->sched, struct amdgpu_ring, sched);
		return ring->adev == adev;
    ...
}

Since the foreign scheduler is not embedded in an amdgpu_ring, this accesses
memory outside the struct. If the foreign scheduler was per-context and
already destroyed by closing the context, could this also result in a
use-after-free?

[Severity: High]
This is a pre-existing issue, but pvr_queue_fence_is_native dereferences
sched_fence->sched->ops on foreign fences, which can lead to a
use-after-free if the foreign scheduler was destroyed.

If a userspace process creates a job on a DRM driver that allocates
per-context schedulers, exports the dma_fence, closes the context (which
frees the scheduler), and then submits a job to the Imagination PVR driver
passing the exported fence as a dependency:

drivers/gpu/drm/imagination/pvr_queue.c:pvr_queue_fence_is_native() {
    ...
	struct drm_sched_fence *sched_fence = f ? to_drm_sched_fence(f) : NULL;

	if (sched_fence &&
	    sched_fence->sched->ops == &pvr_queue_sched_ops)
		return true;
    ...
}

Because the foreign per-context scheduler was already freed, will accessing
sched_fence->sched->ops result in a use-after-free?

> diff --git a/drivers/gpu/drm/scheduler/sched_fence.c b/drivers/gpu/drm/scheduler/sched_fence.c
> index 096fe28aa9c9e..a944eeeb25bd7 100644
> --- a/drivers/gpu/drm/scheduler/sched_fence.c
> +++ b/drivers/gpu/drm/scheduler/sched_fence.c

[ ... ]

> @@ -228,6 +234,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;

[Severity: High]
Does caching the name pointer fully fix the use-after-free for drivers like
drm/panthor and drm/xe that dynamically allocate the timeline name?

In drm/panthor, queue->name is dynamically allocated and freed immediately
via kfree upon queue teardown:

drivers/gpu/drm/panthor/panthor_sched.c:group_create_queue() {
    ...
	queue->name = kasprintf(GFP_KERNEL, "panthor-queue-%llu-%u-%u", drm_client_id, gid, qid);
    ...
}

If an exported dma_fence held in a sync_file outlives the queue, and
userspace later calls SYNC_IOC_FILE_INFO, won't
drm_sched_fence_get_timeline_name return this cached pointer which now
points to freed memory?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260902105808.1541063-1-malhyuk97@gmail.com?part=1