Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] KUnit assertion failure aborts the test without tearing down the DRM scheduler, leading to a use-after-free crash. --
commit 5e3b2d1526bb334b5c71995b67ba48f0b45424d6 Author: Jonghyuk Kim(MalHyuk) <[email protected]> drm/sched/tests: add a UAF regression test for the timeline name This patch introduces a KUnit test to reproduce a use-after-free issue related to the drm_sched_fence timeline name. It submits a job on a mock scheduler and verifies the timeline name can be safely queried after the scheduler is freed. > diff --git a/drivers/gpu/drm/scheduler/tests/tests_integration.c > b/drivers/gpu/drm/scheduler/tests/tests_integration.c > new file mode 100644 > index 0000000000000..4a2d5571440d2 > --- /dev/null > +++ b/drivers/gpu/drm/scheduler/tests/tests_integration.c [ ... ] > +static void drm_sched_dma_fence_uaf(struct kunit *test) > +{ > + struct drm_mock_sched_entity *entity; > + struct drm_mock_scheduler *sched; > + struct drm_mock_sched_job *job; > + struct dma_fence *finished; > + const char __rcu *name; > + bool done; > + > + sched = drm_mock_sched_new(test, MAX_SCHEDULE_TIMEOUT); > + entity = drm_mock_sched_entity_new(test, DRM_SCHED_PRIORITY_NORMAL, > + sched); > + job = drm_mock_sched_job_new(test, entity); > + > + /* The s_fence is only created by drm_sched_job_arm(). */ > + drm_mock_sched_job_submit(job); > + > + /* Independent reference on the finished fence == userspace sync_file. > */ > + finished = dma_fence_get(&job->base.s_fence->finished); > + > + /* Let the job get scheduled (hw fence created), then signal + finish. > */ > + done = drm_mock_sched_job_wait_scheduled(job, HZ); > + KUNIT_ASSERT_TRUE(test, done); [Severity: Medium] Will a failure here in drm_sched_dma_fence_uaf() abort the test and skip the drm_mock_sched_fini() teardown? If this assertion fails, the test thread aborts immediately. Because drm_mock_sched_fini() is bypassed, any active kernel mechanisms from the DRM scheduler might still hold references to sched->base. When KUnit's automated cleanup runs (since sched was allocated with kunit_kzalloc), could those mechanisms access the freed memory and cause a use-after-free crash in the test runner? > + drm_mock_sched_advance(sched, 1); > + done = drm_mock_sched_job_wait_finished(job, HZ); > + KUNIT_ASSERT_TRUE(test, done); [Severity: Medium] Similarly, if this job finish assertion fails, does aborting the test also bypass the manual cleanup phase below, causing the same use-after-free issue during KUnit teardown? > + > + /* > + * Free the per-context scheduler while the finished fence is held. > + * kunit_kfree() releases the backing memory immediately (rather than at > + * test teardown) so that fence->sched becomes a dangling pointer now. > + */ > + drm_mock_sched_entity_free(entity); > + drm_mock_sched_fini(sched); > + kunit_kfree(test, sched); -- Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=3
