Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] Unbounded `job_count` allows memory exhaustion and memcg limit bypass (Denial of Service). -- commit 25d3cd6d4d07a127ac97a2a68ff62409e8f7d1fd Author: Haoming Gao <[email protected]> accel/rocket: Propagate job submission errors This commit modifies rocket_ioctl_submit() to return the first error encountered during job submission and stops processing remaining jobs, leaving previously queued jobs intact. > diff --git a/drivers/accel/rocket/rocket_job.c > b/drivers/accel/rocket/rocket_job.c > --- a/drivers/accel/rocket/rocket_job.c > +++ b/drivers/accel/rocket/rocket_job.c > @@ -647,8 +647,11 @@ int rocket_ioctl_submit(struct drm_device *dev, void > *data, struct drm_file *fil > } > > > - for (i = 0; i < args->job_count; i++) > - rocket_ioctl_submit_job(dev, file, &jobs[i]); > + for (i = 0; i < args->job_count; i++) { > + ret = rocket_ioctl_submit_job(dev, file, &jobs[i]); > + if (ret) > + goto exit; > + } [Severity: High] This isn't a bug introduced by this patch, but is it possible for an unprivileged user to exhaust system memory here? The loop iterates based on args->job_count without an apparent upper bound. During each iteration, rocket_ioctl_submit_job() allocates struct rocket_job, task arrays, and DRM scheduler objects. Because these are allocated using kzalloc_obj and kvmalloc_objs (which default to GFP_KERNEL without __GFP_ACCOUNT), they are not charged to the caller's memory cgroup. Could a user pass a massive job_count to the ioctl via the DRM render node to bypass container limits and trigger a system-wide out of memory condition? > > exit: > kvfree(jobs); -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=3
