Re: [PATCH v2] leds: pwm: Annotate leds[] with __counted_by()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The addition of the `__counted_by(num_leds)` annotation causes an unconditional out-of-bounds trap during probe.
--

commit f2069ade09481403f091ed2758ef698b0c75c2cc
Author: Mert Seftali <mertsftl@gmail.com>

leds: pwm: Annotate leds[] with __counted_by()

This commit adds the __counted_by(num_leds) attribute to the flexible array
member leds[] in struct led_pwm_priv for bounds checking. It also updates
led_pwm_add() to accept the led_pwm_data element directly, leaving num_leds
to be incremented in the caller.

> diff --git a/drivers/leds/leds-pwm.c b/drivers/leds/leds-pwm.c
> index 6c1f2f50ff854..dabdf04235826 100644
> --- a/drivers/leds/leds-pwm.c
> +++ b/drivers/leds/leds-pwm.c
> @@ -36,7 +36,7 @@ struct led_pwm_data {
>  
>  struct led_pwm_priv {
>  	int num_leds;
> -	struct led_pwm_data leds[];
> +	struct led_pwm_data leds[] __counted_by(num_leds);
>  };

[ ... ]

> @@ -193,9 +191,10 @@ static int led_pwm_create_fwnode(struct device *dev, struct led_pwm_priv *priv)
>  
>  		led.default_state = led_init_default_state_get(fwnode);
>  
> -		ret = led_pwm_add(dev, priv, &led, fwnode);
> +		ret = led_pwm_add(dev, &priv->leds[priv->num_leds], &led, fwnode);

[Severity: High]
Does evaluating &priv->leds[priv->num_leds] before incrementing num_leds
trigger an out-of-bounds trap under UBSAN_BOUNDS or FORTIFY_SOURCE?

Because leds is now annotated with __counted_by(num_leds), the compiler
expects the valid indices to be less than num_leds. When this loop starts
in led_pwm_create_fwnode(), priv->num_leds is initially 0. Taking the address
of index 0 when the count is 0 will fail the bounds check and trigger a
splat during driver probe.

>  		if (ret)
>  			return ret;
> +		priv->num_leds++;
>  	}
>  
>  	return 0;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260702155452.67594-1-mertseftali@web.de?part=1