From: sashiko-bot@kernel.org
To: "Andre Luiz Batista Bueno" <andrebueno.mac@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2] drm/amdgpu: deduplicate JPEG v5.0 interrupt routine
Date: Thu, 11 Jun 2026 10:59:13 +0000 [thread overview]
Message-ID: <20260611105913.69ABE1F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260611024211.233876-1-andrebueno.mac@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Missing bounds check on `entry->node_id` before array indexing on `node_id_to_phys_map` can lead to an out-of-bounds memory read.
--
commit 18102389ca6554c76ab0eea5128ed6304f9d3003
Author: Andre Luiz Batista Bueno <andrebueno.mac@gmail.com>
drm/amdgpu: deduplicate JPEG v5.0 interrupt routine
Both jpeg_v5_0_1.c and jpeg_v5_0_2.c implement identical interrupt
processing routines. To avoid code duplication, make the implementation
in jpeg_v5_0_1.c non-static and call it directly from jpeg_v5_0_2.c.
> diff --git a/drivers/gpu/drm/amd/amdgpu/jpeg_v5_0_1.c b/drivers/gpu/drm/amd/amdgpu/jpeg_v5_0_1.c
> index 250316704dfac..2b8d8f4ca30d2 100644
> --- a/drivers/gpu/drm/amd/amdgpu/jpeg_v5_0_1.c
> +++ b/drivers/gpu/drm/amd/amdgpu/jpeg_v5_0_1.c
> @@ -755,7 +755,7 @@ static int jpeg_v5_0_1_set_ras_interrupt_state(struct amdgpu_device *adev,
>
>
>
> -static int jpeg_v5_0_1_process_interrupt(struct amdgpu_device *adev,
> +int jpeg_v5_0_1_process_interrupt(struct amdgpu_device *adev,
> struct amdgpu_irq_src *source,
> struct amdgpu_iv_entry *entry)
> {
[Severity: High]
This is a pre-existing issue, but since this function is being exported to be
shared by other JPEG v5.0 blocks, could an out-of-bounds array access occur
here?
Looking at the beginning of jpeg_v5_0_1_process_interrupt():
u32 i, inst;
i = node_id_to_phys_map[entry->node_id];
The entry->node_id is extracted from the GPU's Interrupt Ring buffer using
an 8-bit mask, allowing values up to 255. However, node_id_to_phys_map is
defined globally with a fixed size of NODEID_MAX (15 elements).
Without a bounds check verifying entry->node_id < NODEID_MAX before indexing
the array, could a malformed hardware interrupt payload cause the driver to
read out-of-bounds memory?
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260611024211.233876-1-andrebueno.mac@gmail.com?part=1
next prev parent reply other threads:[~2026-06-11 10:59 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-09 2:03 [PATCH V1 RESEND] drm/amdgpu: deduplicate JPEG v5.0 interrupt routine Andre Luiz Batista Bueno
2026-05-11 14:55 ` Alex Deucher
2026-06-11 2:40 ` [PATCH v2] " Andre Luiz Batista Bueno
2026-06-11 10:59 ` sashiko-bot [this message]
2026-06-24 3:30 ` [PATCH V2 RESEND] " Andre Luiz Batista Bueno
2026-06-24 7:56 ` sashiko-bot
-- strict thread matches above, loose matches on Subject: below --
2026-07-08 16:28 [PATCH V2] " Andre Luiz Batista Bueno
2026-07-10 13:20 ` Alex Deucher
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=20260611105913.69ABE1F00893@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=andrebueno.mac@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=sashiko-reviews@lists.linux.dev \
/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.