From: Pavitra Jha <jhapavitra98@gmail.com>
To: alexander.deucher@amd.com, christian.koenig@amd.com,
airlied@gmail.com, simona@ffwll.ch
Cc: amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org,
Pavitra Jha <jhapavitra98@gmail.com>
Subject: [PATCH v2] drm/amdgpu/discovery: validate table offset before IP discovery header cast
Date: Wed, 8 Jul 2026 02:18:34 -0400 [thread overview]
Message-ID: <20260708061835.111986-1-jhapavitra98@gmail.com> (raw)
In-Reply-To: <20260624184444.D4A401F000E9@smtp.kernel.org>
Sashiko AI review of the previous fix flagged three remaining gaps in
the discovery blob parser, all stemming from the same root cause: the
ip_discovery_header pointer itself is constructed from a firmware-
controlled offset with no validation before the cast.
ihdr = (struct ip_discovery_header *)(discovery_bin +
le16_to_cpu(bhdr->table_list[IP_DISCOVERY].offset));
This offset is a firmware-controlled u16 read directly from the
discovery blob's table_list, with no bounds check against
adev->discovery.size before being used to construct ihdr. Every
subsequent read from ihdr, including num_dies and die_info[], is
downstream of this unchecked pointer.
The other two items in that review (unbounded ip_offset advancement
via num_base_address, and num_dies exceeding die_info[]'s capacity)
were already addressed in the previous fix.
Fix by validating the table offset in amdgpu_discovery_get_table_info(),
which is the common path used by all callers except
amdgpu_discovery_read_harvest_bit_per_ip() (which reads
table_list[IP_DISCOVERY].offset directly rather than going through
get_table_info()). Add the equivalent check at that direct access site
as well, so all paths that construct an ip_discovery_header pointer
from a table offset are covered.
The check validates the offset itself against adev->discovery.size,
independent of any specific downstream struct size, since
get_table_info() is shared across ten different table types
(IP_DISCOVERY, HARVEST_INFO, GC, MALL_INFO, VCN_INFO, NPS_INFO, and
others) each with differently-sized table structures.
Fixes: d0c647a6aae2 ("drm/amdgpu/discovery: support new discovery binary header")
Cc: stable@vger.kernel.org
Signed-off-by: Pavitra Jha <jhapavitra98@gmail.com>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
index b4ee5fc8e..9b55c56cb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
@@ -564,6 +564,12 @@ static int amdgpu_discovery_get_table_info(struct amdgpu_device *adev,
return -EINVAL;
}
+ if (le16_to_cpu((*info)->offset) >= adev->discovery.size) {
+ dev_err(adev->dev, "invalid table offset %u for table_id %u\n",
+ le16_to_cpu((*info)->offset), table_id);
+ return -EINVAL;
+ }
+
return 0;
}
@@ -766,6 +772,14 @@ static void amdgpu_discovery_read_harvest_bit_per_ip(struct amdgpu_device *adev,
int i, j;
bhdr = (struct binary_header *)discovery_bin;
+
+ if (le16_to_cpu(bhdr->table_list[IP_DISCOVERY].offset) >=
+ adev->discovery.size) {
+ dev_err(adev->dev, "invalid IP_DISCOVERY table offset %u\n",
+ le16_to_cpu(bhdr->table_list[IP_DISCOVERY].offset));
+ return;
+ }
+
ihdr = (struct ip_discovery_header
*)(discovery_bin +
le16_to_cpu(bhdr->table_list[IP_DISCOVERY].offset));
--
2.53.0
next parent reply other threads:[~2026-07-08 6:18 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20260624184444.D4A401F000E9@smtp.kernel.org>
2026-07-08 6:18 ` Pavitra Jha [this message]
2026-07-08 14:54 ` [PATCH v2] drm/amdgpu/discovery: validate table offset before IP discovery header cast 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=20260708061835.111986-1-jhapavitra98@gmail.com \
--to=jhapavitra98@gmail.com \
--cc=airlied@gmail.com \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=simona@ffwll.ch \
--cc=stable@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox