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

Pre-existing issues:
- [High] Pre-existing UAF in KUnit tests due to un-canceled background work on 
test failure.
--

commit a8f2ea9fa48640427fb6cda0751abea77a6dd44f
Author: Shixiong Ou <[email protected]>

drm/sched: Create a fake device for KUnit tests

The DRM scheduler KUnit tests pass NULL for the dev field in
drm_sched_init_args, which causes a NULL-pointer dereference in the
drm_sched_job trace event. This patch gives the mock scheduler a fake
device with kunit_device_register(), ensuring it is cleaned up at test
exit.

> diff --git a/drivers/gpu/drm/scheduler/tests/mock_scheduler.c 
> b/drivers/gpu/drm/scheduler/tests/mock_scheduler.c
> index 8e9ae7d980eb2..6a21e0b40c6d7 100644
> --- a/drivers/gpu/drm/scheduler/tests/mock_scheduler.c
> +++ b/drivers/gpu/drm/scheduler/tests/mock_scheduler.c
> @@ -297,11 +300,19 @@ struct drm_mock_scheduler *drm_mock_sched_new(struct 
> kunit *test, long timeout)
>               .name           = "drm-mock-scheduler",
>       };
>       struct drm_mock_scheduler *sched;
> +     struct device *dev;
> +     char name[64];
>       int ret;
>  
>       sched = kunit_kzalloc(test, sizeof(*sched), GFP_KERNEL);

[Severity: High]
This isn't a bug introduced by this patch, but I noticed a pre-existing
use-after-free issue in the KUnit tests due to uncanceled background work
on test failure.

Because sched is allocated with kunit_kzalloc() here, KUnit's automatic
garbage collection frees the memory when a test exits or aborts on failure.
However, tests in tests_basic.c use assertions that abort immediately:

drivers/gpu/drm/scheduler/tests/tests_basic.c:drm_sched_basic_cancel() {
    ...
        done = drm_mock_sched_job_wait_scheduled(job, HZ);
        KUNIT_ASSERT_TRUE(test, done);

        drm_mock_sched_entity_free(entity);
        drm_mock_sched_fini(sched);
}

If the KUNIT_ASSERT_TRUE() assertion fails, drm_mock_sched_fini() is skipped.
The sched memory is freed by KUnit, but the background work items 
(work_run_job, work_tdr) and workqueues queued by drm_sched_init() are never
canceled. 

Could these work items eventually execute, accessing the freed sched memory
and causing a kernel crash?

This same unhandled cleanup path appears in other tests, such as
drm_sched_test_credits():

drivers/gpu/drm/scheduler/tests/tests_basic.c:drm_sched_test_credits() {
    ...
        done = drm_mock_sched_job_wait_scheduled(job[0], HZ);
        KUNIT_ASSERT_TRUE(test, done);
    ...
        drm_mock_sched_fini(sched);
}

>       KUNIT_ASSERT_NOT_NULL(test, sched);
>  
> +     snprintf(name, sizeof(name), "%s-%u", args.name, instance++);
> +     dev = kunit_device_register(test, name);
> +     KUNIT_ASSERT_NOT_ERR_OR_NULL(test, dev);
> +
> +     args.dev = dev;
> +
>       ret = drm_sched_init(&sched->base, &args);
>       KUNIT_ASSERT_EQ(test, ret, 0);

-- 
Sashiko AI review ยท 
https://sashiko.dev/#/patchset/[email protected]?part=1

Reply via email to