Re: [PATCH v4 04/11] arm64: dts: qcom: x1e80100-crd: Add pm8010 CRD pmic,id=m regulators

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] The `pm8010_vreg_data` array in the RPMh regulator driver lacks a terminating empty `{}` sentinel.
--

--- Patch [4]: [PATCH v4 04/11] arm64: dts: qcom: x1e80100-crd: Add pm8010 CRD pmic,id=m regulators ---
commit 047315d3629a65ebc6a0299afcf53675ba20171b
Author: Bryan O'Donoghue <bryan.odonoghue@linaro.org>

arm64: dts: qcom: x1e80100-crd: Add pm8010 CRD pmic,id=m regulators

This patch adds rpmh regulator definitions for the pm8010 CRD pmic. This
regulator set provides vreg_l3m_1p8, the regulator for the ov08x40 RGB
sensor on the CRD.

> diff --git a/arch/arm64/boot/dts/qcom/x1-crd.dtsi b/arch/arm64/boot/dts/qcom/x1-crd.dtsi
> index a9c5c523575ee..7b9a40a7b9a95 100644
> --- a/arch/arm64/boot/dts/qcom/x1-crd.dtsi
> +++ b/arch/arm64/boot/dts/qcom/x1-crd.dtsi
> @@ -897,6 +897,36 @@ vreg_l3j_0p8: ldo3 {
>  			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
>  		};
>  	};
> +
> +	regulators-8 {
> +		compatible = "qcom,pm8010-rpmh-regulators";

[Severity: High]
This isn't a bug introduced by this patch, but I noticed a potential problem
in the rpmh regulator driver when looking at the pm8010 regulators.

The pm8010_vreg_data array in drivers/regulator/qcom-rpmh-regulator.c lacks a
terminating empty {} sentinel:

drivers/regulator/qcom-rpmh-regulator.c:
static const struct rpmh_vreg_init_data pm8010_vreg_data[] = {
	RPMH_VREG("ldo1",  LDO,  1, &pmic5_nldo502,   "vdd-l1-l2"),
	RPMH_VREG("ldo2",  LDO,  2, &pmic5_nldo502,   "vdd-l1-l2"),
	RPMH_VREG("ldo3",  LDO,  3, &pmic5_pldo502ln, "vdd-l3-l4"),
	RPMH_VREG("ldo4",  LDO,  4, &pmic5_pldo502ln, "vdd-l3-l4"),
	RPMH_VREG("ldo5",  LDO,  5, &pmic5_pldo502,   "vdd-l5"),
	RPMH_VREG("ldo6",  LDO,  6, &pmic5_pldo502ln, "vdd-l6"),
	RPMH_VREG("ldo7",  LDO,  7, &pmic5_pldo502,   "vdd-l7"),
};

Because rpmh_regulator_init_vreg() iterates over this array using
rpmh_data->name as the loop condition, if a device tree specifies a regulator
name not present in this array, the loop will read past the end of the array.

Could this out-of-bounds read cause the PMIC to misconfigure a regulator if a
name happens to match adjacent memory, or lead to a kernel panic if it
reaches unmapped memory before encountering a NULL pointer?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260708-x1e-camss-csi2-phy-dtsi-v4-0-572348ad1b2a@linaro.org?part=4