From: Lee Jones <lee@kernel.org>
To: sashiko-reviews@lists.linux.dev
Cc: Mert Seftali <mertsftl@gmail.com>, linux-leds@vger.kernel.org
Subject: Re: [PATCH v2] leds: pwm: Annotate leds[] with __counted_by()
Date: Thu, 9 Jul 2026 10:13:56 +0100 [thread overview]
Message-ID: <20260709091356.GA2045740@google.com> (raw)
In-Reply-To: <20260702160459.9BC4E1F00A3A@smtp.kernel.org>
On Thu, 02 Jul 2026, sashiko-bot@kernel.org wrote:
> 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.
Can you provide comment or remediation please?
> --
>
> 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
--
Lee Jones
next prev parent reply other threads:[~2026-07-09 9:14 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-02 15:54 [PATCH v2] leds: pwm: Annotate leds[] with __counted_by() Mert Seftali
2026-07-02 16:04 ` sashiko-bot
2026-07-09 9:13 ` Lee Jones [this message]
2026-07-09 13:57 ` Mert Seftali
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260709091356.GA2045740@google.com \
--to=lee@kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=mertsftl@gmail.com \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.