From: sashiko-bot@kernel.org
To: "Michał Grzelak" <michal.grzelak@intel.com>
Cc: intel-xe@lists.freedesktop.org, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v12 6/8] drm/i915: override Snps's VS/PE when requested
Date: Fri, 04 Sep 2026 12:53:59 +0000 [thread overview]
Message-ID: <20260904125359.B930D1F00A3D@smtp.kernel.org> (raw)
In-Reply-To: <20260904123148.2165596-7-michal.grzelak@intel.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Missing bounds checks on VBT-provided 'num_tables' and 'num_columns' when calculating array offsets leads to out-of-bounds read vulnerabilities when parsing VS/PE override tables.
- [High] Returning an empty buffer translation table when the VBT block is missing causes callers to access negative array indices (e.g., `entries[-1]`).
--
commit 4a1fde509366b85ca4550f56196259dc3545219c
Author: Michał Grzelak <michal.grzelak@intel.com>
drm/i915: override Snps's VS/PE when requested
This commit adds accessor functions to read the requested Snps VS/PE
table from VBT block 57. It parses the requested table and transforms
the data into the port's buffer for C10 and C20 PHYs.
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c b/drivers/gpu/drm/i915/display/intel_bios.c
> index 1a09f7933e491..be7554c483ad2 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -3880,6 +3880,97 @@ bool intel_bios_encoder_supports_tbt(const struct intel_bios_encoder_data *devda
> return devdata->display->vbt.version >= 209 && devdata->child.tbt;
> }
>
> +static bool
> +validate_vspeo(const struct intel_bios_encoder_data *devdata, bool has_dp)
> +{
> + struct intel_ddi_buf_trans *vspeo;
> +
> + vspeo = devdata->vspeo;
> + if (!vspeo)
> + return false;
[Severity: High]
Does this validation need to ensure the VBT block data was actually parsed?
If VBT block 57 is absent, vspeo might be allocated with num_entries
set to 0, which would pass this check. If intel_bios_get_c20_vspeo returns
this empty vspeo, downstream callers like intel_ddi_buf_trans_get will
return n_entries = 0.
When n_entries = 0 reaches intel_ddi_level(), could it result in level
becoming -1:
drivers/gpu/drm/i915/display/intel_ddi.c:intel_ddi_level() {
...
if (drm_WARN_ON_ONCE(display->drm, level >= n_entries))
level = n_entries - 1;
return level;
}
This would cause callers to access a negative array index on the entries
pointer, leading to a potential crash.
> +
> + if (!has_dp)
> + return false;
> +
> + return true;
> +}
> +
> +const struct intel_ddi_buf_trans *
> +intel_bios_get_c20_vspeo(const struct intel_bios_encoder_data *devdata,
> + bool has_dp, bool is_uhbr)
> +{
> + struct intel_display *display = devdata->display;
> + union intel_ddi_buf_trans_entry *entries = devdata->entries;
> + struct intel_ddi_buf_trans *vspeo = devdata->vspeo;
> + const u32 *tables = display->vbt.vspeo.tables;
> + int num_columns = display->vbt.vspeo.num_columns;
> + int num_rows = display->vbt.vspeo.num_rows;
> + int idx = is_uhbr ? 5 : 4;
> + size_t offset = 0;
> + int level;
> +
> + if (!validate_vspeo(devdata, has_dp))
> + return NULL;
> +
> + offset += idx * num_rows * num_columns;
[Severity: High]
Should there be bounds checking on idx and num_columns here?
Since idx is computed dynamically (up to 5 for C20, and up to 3 for C10)
and multiplied by num_rows and num_columns, the resulting offset
could potentially exceed the size of the VBT block 57 data if num_columns
is unexpectedly large or the block is truncated.
Could this lead to an out-of-bounds read when accessing tables[offset + 2]
below, potentially reading unmapped memory?
> +
> + for (level = 0; level < num_rows; level++) {
> + u32 vswing = tables[offset];
> + u32 pre_cursor = tables[offset + 1];
> + u32 post_cursor = tables[offset + 2];
[ ... ]
> +const struct intel_ddi_buf_trans *
> +intel_bios_get_c10_vspeo(const struct intel_bios_encoder_data *devdata,
> + bool has_dp, int port_clock, bool has_edp)
> +{
> + struct intel_display *display = devdata->display;
> + union intel_ddi_buf_trans_entry *entries = devdata->entries;
> + struct intel_ddi_buf_trans *vspeo = devdata->vspeo;
> + const u32 *tables = display->vbt.vspeo.tables;
> + int num_columns = display->vbt.vspeo.num_columns;
> + int num_rows = display->vbt.vspeo.num_rows;
> + size_t offset = 0;
> + int level, idx;
> +
> + if (!validate_vspeo(devdata, has_dp))
> + return NULL;
> +
> + if (has_edp)
> + idx = port_clock > 540000 ? 3 : 2;
> + else
> + idx = port_clock > 270000 ? 1 : 0;
> +
> + offset += idx * num_rows * num_columns;
[Severity: High]
Similar to the C20 function above, is it possible for this computed
offset to fall outside the bounds of the tables array if num_columns
or the selected idx is too large for the provided VBT data?
> +
> + for (level = 0; level < num_rows; level++) {
> + u32 vswing = tables[offset];
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260904123148.2165596-1-michal.grzelak@intel.com?part=6
next prev parent reply other threads:[~2026-09-04 12:54 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-04 12:31 [PATCH v12 0/8] Vswing / Pre-emphasis Override Michał Grzelak
2026-09-04 12:31 ` [PATCH v12 1/8] drm/i915/bios: search for VBT #57 by default Michał Grzelak
2026-09-04 12:31 ` [PATCH v12 2/8] drm/i915/bios: store VBT #57's metadata in intel_vbt_data Michał Grzelak
2026-09-04 12:43 ` sashiko-bot
2026-09-04 12:31 ` [PATCH v12 3/8] drm/i915/bios: print VS/PE-O port info Michał Grzelak
2026-09-04 12:50 ` sashiko-bot
2026-09-04 12:31 ` [PATCH v12 4/8] drm/i915/bios: de/allocate VS/PE-O buffers for each port Michał Grzelak
2026-09-04 12:46 ` sashiko-bot
2026-09-04 12:31 ` [PATCH v12 5/8] drm/i915/buf_trans: add vfunc for VS/PE-O Michał Grzelak
2026-09-04 12:31 ` [PATCH v12 6/8] drm/i915: override Snps's VS/PE when requested Michał Grzelak
2026-09-04 12:53 ` sashiko-bot [this message]
2026-09-04 12:31 ` [PATCH v12 7/8] drm/i915: override Combo's " Michał Grzelak
2026-09-04 12:59 ` sashiko-bot
2026-09-07 12:27 ` [PATCH v13 " Michał Grzelak
2026-09-04 12:31 ` [PATCH v12 8/8] drm/i915/bios: remove VS/PE-O warning Michał Grzelak
2026-09-04 13:04 ` ✗ CI.checkpatch: warning for Vswing / Pre-emphasis Override (rev7) Patchwork
2026-09-04 13:06 ` ✓ CI.KUnit: success " Patchwork
2026-09-04 13:14 ` ✓ i915.CI.BAT: " Patchwork
2026-09-04 14:06 ` ✓ Xe.CI.BAT: " Patchwork
2026-09-04 23:39 ` ✗ Xe.CI.FULL: failure " Patchwork
2026-09-05 1:07 ` ✗ i915.CI.Full: " Patchwork
2026-09-07 13:17 ` ✗ CI.checkpatch: warning for Vswing / Pre-emphasis Override (rev8) Patchwork
2026-09-07 13:19 ` ✓ CI.KUnit: success " Patchwork
2026-09-07 13:31 ` ✓ i915.CI.BAT: " Patchwork
2026-09-07 14:00 ` ✓ Xe.CI.BAT: " Patchwork
2026-09-07 15:50 ` ✓ Xe.CI.FULL: " Patchwork
2026-09-07 20:37 ` ✓ i915.CI.Full: " Patchwork
2026-09-08 4:33 ` [PATCH v12 0/8] Vswing / Pre-emphasis Override Kandpal, Suraj
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=20260904125359.B930D1F00A3D@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=michal.grzelak@intel.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.