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) <[email protected]> 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/[email protected]?part=1
