Re: [PATCH] drm/bridge: sii902x: Read "sil,i2s-data-lanes" as u32

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Missing bounds check on 'sil,i2s-data-lanes' values leads to out-of-bounds array read.
--

commit 460b61bf52ca50a54beb619610726eb8680ea41a
Author: Rob Herring (Arm) <robh@kernel.org>

drm/bridge: sii902x: Read "sil,i2s-data-lanes" as u32

The commit updates the sii902x driver to read the "sil,i2s-data-lanes"
device tree property as a u32 array instead of a u8 array. This change makes
the driver follow the documented DT element size and binding specifications.

> diff --git a/drivers/gpu/drm/bridge/sii902x.c b/drivers/gpu/drm/bridge/sii902x.c
> index ea543be4ae3e2..7c90194449e1a 100644
> --- a/drivers/gpu/drm/bridge/sii902x.c
> +++ b/drivers/gpu/drm/bridge/sii902x.c
> @@ -862,7 +862,7 @@ static int sii902x_audio_codec_init(struct sii902x *sii902x,
>  		.max_i2s_channels = 0,
>  		.no_capture_mute = 1,
>  	};
> -	u8 lanes[4];
> +	u32 lanes[4];

[Severity: High]
This isn't a bug introduced by this patch, but does changing the type of lanes
from u8 to u32 increase the severity of a potential out-of-bounds read?

Later in sii902x_audio_codec_init() around line 894 of
drivers/gpu/drm/bridge/sii902x.c, the values parsed from the device tree are
used directly as indices into the i2s_lane_id array:

	for (i = 0; i < num_lanes; i++)
		sii902x->audio.i2s_fifo_sequence[i] |= audio_fifo_id[i] |
			i2s_lane_id[lanes[i]] | SII902X_TPI_I2S_FIFO_ENABLE;

Because i2s_lane_id has a fixed size of 4 elements and there is no validation
on the parsed values, a malformed device tree could provide a value larger
than 3. When lanes was an array of u8, the read offset was limited, but as a
u32 it could hit unmapped memory and trigger a kernel oops during device probe.

Could we add a bounds check to ensure the values are within the correct range?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260612215205.1887206-1-robh@kernel.org?part=1