Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] Unbounded unaccounted memory allocations in job submission paths based on user-controlled counts. -- commit 6abaeaa93e812673bb771d67a15b960baf454dc7 Author: [email protected] <[email protected]> drm/imagination: Fix user array stride in pvr_set_uobj_array() This commit corrects the pointer arithmetic and padding clearing in pvr_set_uobj_array to ensure correct element copies. It advances the userspace pointer by the stride and the kernel pointer by the object size. Cc: [email protected] # v6.8+ > diff --git a/drivers/gpu/drm/imagination/pvr_drv.c > b/drivers/gpu/drm/imagination/pvr_drv.c > index b20c462bcba0b..58e24f133bec7 100644 > --- a/drivers/gpu/drm/imagination/pvr_drv.c > +++ b/drivers/gpu/drm/imagination/pvr_drv.c [ ... ] [Severity: High] This is a pre-existing issue, but while reviewing this subsystem I noticed a potential problem with unbounded allocations in the job submission paths. In drivers/gpu/drm/imagination/pvr_job.c:pvr_submit_jobs(): err = PVR_UOBJ_GET_ARRAY(job_args, &args->jobs); ... job_data = kvmalloc_objs(*job_data, args->jobs.count, GFP_KERNEL | __GFP_ZERO); And similarly in drivers/gpu/drm/imagination/pvr_job.c:pvr_job_data_init(): err = PVR_UOBJ_GET_ARRAY(job_data_out[i].sync_ops, &job_args[i].sync_ops); Since args->jobs.count and sync_ops.count come directly from userspace, can a malicious local user with access to the DRM render node issue a submit jobs ioctl with an arbitrarily large count? Because these allocations use GFP_KERNEL without the __GFP_ACCOUNT flag, __GFP_NORETRY, or an upper bound validation, could a massive allocation request bypass memory cgroup limits and trigger the global OOM killer, leading to a system-wide denial of service? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
