From: sashiko-bot@kernel.org
To: shuvampandey1@gmail.com
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/imagination: Fix user array stride in pvr_set_uobj_array()
Date: Mon, 15 Jun 2026 21:56:54 +0000 [thread overview]
Message-ID: <20260615215655.12DFF1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <178155996993.4848.8618351576278880213@gmail.com>
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: shuvampandey1@gmail.com <shuvampandey1@gmail.com>
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: stable@vger.kernel.org # 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/178155996993.4848.8618351576278880213@gmail.com?part=1
prev parent reply other threads:[~2026-06-15 21:56 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-15 21:46 [PATCH] drm/imagination: Fix user array stride in pvr_set_uobj_array() shuvampandey1
2026-06-15 21:56 ` sashiko-bot [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260615215655.12DFF1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=shuvampandey1@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.