[PATCH] regulator: s5m8767: Bounds check id indexing into arrays

[PATCH] regulator: s5m8767: Bounds check id indexing into arrays

[Kees Cook]

The compiler has no way to know if "id" is within the array bounds of
the regulators array. Add a check for this and a build-time check that
the regulators and reg_voltage_map arrays are sized the same. Seen with
GCC 13:

../drivers/regulator/s5m8767.c: In function 's5m8767_pmic_probe':
../drivers/regulator/s5m8767.c:936:35: warning: array subscript [0, 36] is outside array bounds of 'struct regulator_desc[37]' [-Warray-bounds=]
  936 |                         regulators[id].vsel_reg =
      |                         ~~~~~~~~~~^~~~

Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: linux-samsung-soc@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
---
 drivers/regulator/s5m8767.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/regulator/s5m8767.c b/drivers/regulator/s5m8767.c
index 35269f998210..754c6fcc6e64 100644
--- a/drivers/regulator/s5m8767.c
+++ b/drivers/regulator/s5m8767.c
@@ -923,10 +923,14 @@ static int s5m8767_pmic_probe(struct platform_device *pdev)
 
 	for (i = 0; i < pdata->num_regulators; i++) {
 		const struct sec_voltage_desc *desc;
-		int id = pdata->regulators[i].id;
+		unsigned int id = pdata->regulators[i].id;
 		int enable_reg, enable_val;
 		struct regulator_dev *rdev;
 
+		BUILD_BUG_ON(ARRAY_SIZE(regulators) != ARRAY_SIZE(reg_voltage_map));
+		if (WARN_ON_ONCE(id >= ARRAY_SIZE(regulators)))
+			continue;
+
 		desc = reg_voltage_map[id];
 		if (desc) {
 			regulators[id].n_voltages =
-- 
2.34.1

Re: [PATCH] regulator: s5m8767: Bounds check id indexing into arrays

[Krzysztof Kozlowski]

On 28/01/2023 01:53, Kees Cook wrote:
> The compiler has no way to know if "id" is within the array bounds of

It has. For the CONFIG_OF (the only way parent device - sec-core.c - can
match now), the id is assigned in s5m8767_pmic_dt_parse_pdata() and kept
within limits <0,ARRAY_SIZE(regulators)-1>.

The device cannot match via old non-OF way, so there is no real bug to
fix. You are silencing compiler warning, which is fine, but it's not a
real case. The code is not easy to follow, so I am fine with such checks
(WARN_ON_ONCE). The BUILD_BUG_ON is indeed meaningful.

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>


Best regards,
Krzysztof

Re: [PATCH] regulator: s5m8767: Bounds check id indexing into arrays

[Mark Brown]

On Fri, 27 Jan 2023 16:53:58 -0800, Kees Cook wrote:
> The compiler has no way to know if "id" is within the array bounds of
> the regulators array. Add a check for this and a build-time check that
> the regulators and reg_voltage_map arrays are sized the same. Seen with
> GCC 13:
> 
> ../drivers/regulator/s5m8767.c: In function 's5m8767_pmic_probe':
> ../drivers/regulator/s5m8767.c:936:35: warning: array subscript [0, 36] is outside array bounds of 'struct regulator_desc[37]' [-Warray-bounds=]
>   936 |                         regulators[id].vsel_reg =
>       |                         ~~~~~~~~~~^~~~
> 
> [...]

Applied to

   broonie/regulator.git for-next

Thanks!

[1/1] regulator: s5m8767: Bounds check id indexing into arrays
      commit: e314e15a0b58f9d051c00b25951073bcdae61953

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark