Re: [PATCH] leds: lp50xx: Read default intensity from devicetree

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found no new issues
in this patch, but noticed 1 related pre-existing issue it does not
introduce:
- [Critical] leds: lp50xx: heap out-of-bounds access in
  lp50xx_brightness_set() [1]
--

commit 79b801d6a9355ec03170294fd226b03df2a33733
Author: Tobias Johansson <tobias.johansson@axis.com>

leds: lp50xx: Read default intensity from devicetree

This commit reads the default-intensity property from device tree for each
LP50xx multicolor sub-LED component during probe.

> diff --git a/drivers/leds/leds-lp50xx.c b/drivers/leds/leds-lp50xx.c
> index 20bfb315bda1d..019a3e3cad057 100644
> --- a/drivers/leds/leds-lp50xx.c
> +++ b/drivers/leds/leds-lp50xx.c
> @@ -522,6 +522,8 @@ static int lp50xx_probe_dt(struct lp50xx *priv)
>  				dev_err(priv->dev, "reg %i out of range\n", multi_index);
>  				return -EINVAL;
>  			}
> +			fwnode_property_read_u32(led_node, "default-intensity",
> +						 &mc_led_info[multi_index].intensity);
>  
>  			mc_led_info[multi_index].color_index = color_id;
>  			mc_led_info[multi_index].max_intensity = 255;

[Severity: Critical]
This problem wasn't introduced by this patch, but can num_colors exceed
LP50XX_LEDS_PER_MODULE and cause an out-of-bounds access on mc_led_info[]
[1]?

mc_led_info is allocated with LP50XX_LEDS_PER_MODULE (3) elements, and
lp50xx_probe_dt() checks that multi_index < LP50XX_LEDS_PER_MODULE, but
num_colors is incremented unconditionally for every child node. If a
device tree defines more than three sub-LED nodes that reuse valid reg
indices, led->mc_cdev.num_colors will exceed 3, causing
multi_intensity_store() and lp50xx_brightness_set() to read and write past
the end of subled_info[].

[1] https://sashiko.dev/#/bug/linux-a0c116ab-2f34-4f53-a007-d7a42f28677b

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261109-b4-leds-lp50xx-default-intensity-v1-1-0a04a3533df6@axis.com?part=1