Re: [PATCH v5 3/3] accel/rocket: Propagate job submission errors

[sashiko-bot@kernel.org]

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 <Naixumogu@whut.edu.cn>

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/20260828064152.37822-1-Naixumogu@whut.edu.cn?part=3