Re: [PATCH v12 4/8] drm/i915/bios: de/allocate VS/PE-O buffers for each port

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Missing validation for `num_rows` allows allocation of a zero-length override buffer, leading to ZERO_SIZE_PTR bypass and potential out-of-bounds array access.
--

commit 8e0ea30f286f43a0a8c7581e1d9abc3a9fc3887e
Author: Michał Grzelak <michal.grzelak@intel.com>

drm/i915/bios: de/allocate VS/PE-O buffers for each port

Every devdata needs VS/PE-O dedicated buffers since each port can
request an override. Add intel_ddi_buf_trans{,_entry} pointers into
intel_bios_encoder_data and allocate/free them for the port if requested.

> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c b/drivers/gpu/drm/i915/display/intel_bios.c
> index 9610b794bc147..1a09f7933e491 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
[ ... ]
> @@ -2648,6 +2651,30 @@ static void sanitize_device_type(struct intel_bios_encoder_data *devdata,
>  	devdata->child.device_type |= DEVICE_TYPE_NOT_HDMI_OUTPUT;
>  }
>  
> +static void allocate_vswing_preemph_override(struct intel_bios_encoder_data *devdata)
> +{
> +	int num_rows = devdata->display->vbt.vspeo.num_rows;
> +	union intel_ddi_buf_trans_entry *entries;
> +	struct intel_ddi_buf_trans *vspeo;
> +
> +	if (!intel_bios_encoder_requests_vspeo(devdata))
> +		return;
> +
> +	vspeo = kzalloc_obj(*vspeo);
> +	if (!vspeo)
> +		return;
> +
> +	entries = kzalloc_objs(*entries, num_rows);
> +	if (!entries) {

[Severity: High]
If a system provides a malformed VBT where use_vbt_vswing is true but the
BDB_VSWING_PREEMPH block is missing, could num_rows be 0 here?

When num_rows is 0, kzalloc_objs() returns ZERO_SIZE_PTR. Because
ZERO_SIZE_PTR is not NULL, it bypasses this !entries check.

This results in the creation of a zero-entry table that signals to
downstream code that override data is present. Later, when this table is
fetched by intel_ddi_buf_trans_get() and passed to intel_ddi_level(),
the index is clamped to n_entries - 1 (yielding -1).

Could this lead to an out-of-bounds memory read relative to ZERO_SIZE_PTR
when the caller accesses trans->entries[-1]?

> +		kfree(vspeo);
> +		return;
> +	}
> +
> +	devdata->entries = entries;
> +	devdata->vspeo = vspeo;
> +	devdata->vspeo->num_entries = num_rows;
> +}
> +

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260904123148.2165596-1-michal.grzelak@intel.com?part=4