From: sashiko-bot@kernel.org
To: "Alex Huang" <Alex.Huang2@amd.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 1/4] drm/edid: Parse AMD VSDB for FreeSync refresh range
Date: Tue, 21 Jul 2026 16:54:05 +0000 [thread overview]
Message-ID: <20260721165406.51E381F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260721164430.2121326-2-Alex.Huang2@amd.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Missing payload length validation for AMD VSDB versions 2 and 3 leads to out-of-bounds memory reads.
--
--- Patch [1]: [PATCH 1/4] drm/edid: Parse AMD VSDB for FreeSync refresh range ---
commit 494775781ee504bb22668b33e2cf4cf7e240bfaa
Author: Alex Huang <Alex.Huang2@amd.com>
drm/edid: Parse AMD VSDB for FreeSync refresh range
This commit restructures the AMD VSDB parsing to support FreeSync refresh
ranges. It introduces structures for v1 and v2 payloads and relaxes the
overall minimum length check to accommodate v1 blocks.
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index df3c25bac761d..c9452066b9bee 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
[ ... ]
> @@ -5231,7 +5269,7 @@ static bool cea_db_is_microsoft_vsdb(const struct cea_db *db)
> static bool cea_db_is_amd_vsdb(const struct cea_db *db)
> {
> return cea_db_is_vendor(db, AMD_IEEE_OUI) &&
> - cea_db_payload_len(db) >= AMD_VSDB_V3_PAYLOAD_MIN_LEN &&
> + cea_db_payload_len(db) >= AMD_VSDB_V1_PAYLOAD_LEN &&
> cea_db_payload_len(db) <= AMD_VSDB_V3_PAYLOAD_MAX_LEN;
> }
[ ... ]
> @@ -6431,43 +6469,81 @@ static void drm_parse_microsoft_vsdb(struct drm_connector *connector,
[ ... ]
> static void drm_parse_amd_vsdb(struct drm_connector *connector,
> const struct cea_db *db)
> {
[ ... ]
> + drm_parse_amd_vsdb_v1(info, data);
> +
> + if (common->version >= 2)
> + drm_parse_amd_vsdb_v2(info, data);
> +
> + if (common->version >= 3)
> + drm_parse_amd_vsdb_v3(info, data, cea_db_payload_len(db));
[Severity: High]
Can this lead to an out-of-bounds read if a malformed EDID provides a short
payload but advertises a newer version?
In cea_db_is_amd_vsdb(), the minimum payload length check is relaxed to
AMD_VSDB_V1_PAYLOAD_LEN (8 bytes). However, in drm_parse_amd_vsdb(), if
a block claims to be version 3 but only provides 8 bytes of data, it will
pass the earlier check but still execute drm_parse_amd_vsdb_v2() and
drm_parse_amd_vsdb_v3() here.
Since the v2 and v3 parsing functions expect up to 13 and 15 bytes
respectively, reading these structs from an 8-byte payload will read past
the end of the allocated buffer. Should we verify that cea_db_payload_len(db)
is large enough for the specific version being parsed before calling the v2
and v3 parsing functions?
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260721164430.2121326-1-Alex.Huang2@amd.com?part=1
next prev parent reply other threads:[~2026-07-21 16:54 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-21 16:44 [PATCH 0/4] drm/edid: Parse AMD VSDB FreeSync range in common code Alex Huang
2026-07-21 16:44 ` [PATCH 1/4] drm/edid: Parse AMD VSDB for FreeSync refresh range Alex Huang
2026-07-21 16:54 ` sashiko-bot [this message]
2026-07-21 17:00 ` Mario Limonciello
2026-07-21 16:44 ` [PATCH 2/4] drm/amd/display: Use HDMI FreeSync range from common EDID parser Alex Huang
2026-07-21 17:03 ` sashiko-bot
2026-07-21 16:44 ` [PATCH 3/4] drm/amd/display: Clean up FreeSync capability detection Alex Huang
2026-07-21 16:55 ` sashiko-bot
2026-07-21 16:44 ` [PATCH 4/4] drm/amd/display: Remove unused DMCU/DMUB EDID CEA parser Alex Huang
2026-07-21 16:59 ` sashiko-bot
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=20260721165406.51E381F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=Alex.Huang2@amd.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.