Re: [PATCH v2 2/3] pinctrl: mediatek: Add driver for MT6858

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Out-of-bounds array read in `mt6858_pull_type` due to missing VEINT pins.
- [High] NULL Pointer Dereference in `mtk_hw_pin_rsel_lookup` when `mediatek,rsel-resistance-in-si-unit` is used.
--

--- Patch [2]: [PATCH v2 2/3] pinctrl: mediatek: Add driver for MT6858 ---
commit 77e15ce1c7cb0516ec8722df8f1589a541d7a5b7
Author: Nikolai Burov <nikolai.burov@jolla.com>

pinctrl: mediatek: Add driver for MT6858

This commit adds a pin controller and gpio driver for the MediaTek MT6858
(Dimensity 7100) SoC.

> diff --git a/drivers/pinctrl/mediatek/pinctrl-mt6858.c b/drivers/pinctrl/mediatek/pinctrl-mt6858.c
> new file mode 100644
> index 0000000000000..07f72d9d531f7
> --- /dev/null
> +++ b/drivers/pinctrl/mediatek/pinctrl-mt6858.c
[ ... ]
> +static const unsigned int mt6858_pull_type[] = {
> +	MTK_PULL_PU_PD_TYPE, /* 0 */
> +	MTK_PULL_PU_PD_TYPE, /* 1 */
[ ... ]
> +	MTK_PULL_PU_PD_TYPE, /* 195 */
> +	MTK_PULL_PU_PD_TYPE, /* 196 */
> +};

[Severity: High]
This array is sized to 197 elements, but the mtk_pins_mt6858 array defines 217
pins, which includes the virtual EINT pins at indices 197-216. When generic
pinconf operations evaluate the bias configuration for these VEINT pins (such
as mtk_pinconf_bias_get_combo() during a debugfs read), won't this result in
an out-of-bounds memory read?

[ ... ]
> +static const struct mtk_pin_soc mt6858_data = {
> +	.reg_cal = mt6858_reg_cals,
> +	.pins = mtk_pins_mt6858,
> +	.npins = ARRAY_SIZE(mtk_pins_mt6858),
> +	.ngrps = ARRAY_SIZE(mtk_pins_mt6858),
> +	.eint_hw = &mt6858_eint_hw,
> +	.eint_pin = eint_pins_mt6858,
> +	.nfuncs = 16,
> +	.gpio_m = 0,
> +	.base_names = mt6858_pinctrl_register_base_names,
> +	.nbase_names = ARRAY_SIZE(mt6858_pinctrl_register_base_names),
> +	.pull_type = mt6858_pull_type,

[Severity: High]
The mt6858_pull_type array configures several pins with the
MTK_PULL_PU_PD_RSEL_TYPE attribute, but the .pin_rsel and .npin_rsel fields
are not initialized in this structure.

If the Device Tree uses the mediatek,rsel-resistance-in-si-unit property,
could this cause a NULL pointer dereference?

The common code in mtk_hw_pin_rsel_lookup() iterates with:

    for (check = 0; check <= hw->soc->npin_rsel - 1; check++)

Since npin_rsel defaults to 0, 0 - 1 underflows to UINT_MAX. The loop would
then immediately evaluate rsel[check].s_pin, resulting in a kernel panic as
rsel is NULL.

> +	.bias_set_combo = mtk_pinconf_bias_set_combo,
> +	.bias_get_combo = mtk_pinconf_bias_get_combo,
> +	.drive_set = mtk_pinconf_drive_set_rev1,
> +	.drive_get = mtk_pinconf_drive_get_rev1,
> +	.adv_drive_get = mtk_pinconf_adv_drive_get_raw,
> +	.adv_drive_set = mtk_pinconf_adv_drive_set_raw,
> +};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260713-mt6858-pinctrl-v2-0-1bd072e3206c@jolla.com?part=2