From: sashiko-bot@kernel.org
To: "Pavitra Jha" <jhapavitra98@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu/discovery: fix OOB read via unchecked die_offset in IP discovery parsing
Date: Wed, 24 Jun 2026 18:44:44 +0000 [thread overview]
Message-ID: <20260624184444.D4A401F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260624183409.1079288-1-jhapavitra98@gmail.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
Pre-existing issues:
- [High] The patch identifies but fails to fix out-of-bounds reads caused by unbounded ip_offset advancement.
- [High] Missing bounds check for firmware-controlled num_dies before accessing the die_info array.
- [High] Missing bounds checks for basic header offsets in the discovery binary parser.
--
commit 9d6788c99594a0d1857e6cde0b70c40338a5e49f
Author: Pavitra Jha <jhapavitra98@gmail.com>
drm/amdgpu/discovery: fix OOB read via unchecked die_offset in IP discovery parsing
This commit adds bounds checking for die_offset against adev->discovery.size
in three IP discovery parsing functions. It aims to prevent out-of-bounds
reads when processing firmware-controlled die_offset values.
> The ip_offset advancement inside the inner loop also uses
> struct_size(ip, base_address, ip->num_base_address) where
> num_base_address is firmware-controlled, enabling unbounded advancement
> past the allocation on each iteration.
[Severity: High]
This is a pre-existing issue, but the commit message identifies this unbounded
advancement as a root cause, yet the patch doesn't seem to include a bounds
check for it in the loop.
Should there be a check against adev->discovery.size for ip_offset inside the
inner loop as well, to prevent reading past the end of the allocation when
dereferencing the advanced ip_offset?
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
> index be5069642a907..41ca01e2bb6fd 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
> @@ -774,6 +774,11 @@ static void amdgpu_discovery_read_harvest_bit_per_ip(struct amdgpu_device *adev,
> /* scan harvest bit of all IP data structures */
[Severity: High]
This is a pre-existing issue, but does the construction of the ihdr pointer
lack bounds checking?
In amdgpu_discovery_read_harvest_bit_per_ip(), ihdr is constructed using an
unchecked offset:
ihdr = (struct ip_discovery_header *)(discovery_bin +
le16_to_cpu(bhdr->table_list[IP_DISCOVERY].offset));
Could an invalid firmware-provided offset cause an out-of-bounds read when
ihdr is later dereferenced?
> for (i = 0; i < num_dies; i++) {
> die_offset = le16_to_cpu(ihdr->die_info[i].die_offset);
[Severity: High]
This is a pre-existing issue, but is it possible for num_dies to exceed the
fixed array size of 16 for die_info?
Since num_dies is firmware-controlled, could an unchecked value cause an
out-of-bounds read when accessing ihdr->die_info[i]?
> + if (die_offset + sizeof(*dhdr) > adev->discovery.size) {
> + dev_err(adev->dev, "invalid die_offset %u in harvest table\n",
> + die_offset);
> + return;
> + }
> dhdr = (struct die_header *)(discovery_bin + die_offset);
> num_ips = le16_to_cpu(dhdr->num_ips);
> ip_offset = die_offset + sizeof(*dhdr);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260624183409.1079288-1-jhapavitra98@gmail.com?part=1
next prev parent reply other threads:[~2026-06-24 18:44 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-24 18:34 [PATCH] drm/amdgpu/discovery: fix OOB read via unchecked die_offset in IP discovery parsing Pavitra Jha
2026-06-24 18:44 ` sashiko-bot [this message]
2026-07-08 6:18 ` [PATCH v2] drm/amdgpu/discovery: validate table offset before IP discovery header cast Pavitra Jha
2026-07-08 6:30 ` sashiko-bot
2026-07-08 14:54 ` Alex Deucher
2026-07-08 15:35 ` Pavitra Jha
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=20260624184444.D4A401F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=jhapavitra98@gmail.com \
--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.