From: sashiko-bot@kernel.org
To: "Rong Zhang" <i@rong.moe>
Cc: linux-leds@vger.kernel.org, lee@kernel.org
Subject: Re: [PATCH v4 08/12] leds: trigger: Do not attach trigger to a removing LED
Date: Sun, 02 Aug 2026 17:31:49 +0000 [thread overview]
Message-ID: <20260802173150.F31FB1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260802-leds-trigger-hw-changed-v4-8-f97e2ca976fe@rong.moe>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Non-atomic update of `led_cdev->flags` causes a data race that can drop the `LED_UNREGISTERING` flag, undermining the use-after-free fix.
--
--- Patch [8]: [PATCH v4 08/12] leds: trigger: Do not attach trigger to a removing LED ---
commit dd467951eb46d9ac1296845c072ca12344efe3da
Author: Rong Zhang <i@rong.moe>
leds: trigger: Do not attach trigger to a removing LED
This commit attempts to fix a race condition where a trigger could attach
to an LED during removal. It sets the LED_UNREGISTERING flag earlier in
led_classdev_unregister() and checks it before attaching a trigger.
> diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
> index 2460fcf0c4690..4158337896bc7 100644
> --- a/drivers/leds/led-class.c
> +++ b/drivers/leds/led-class.c
> @@ -631,6 +631,8 @@ void led_classdev_unregister(struct led_classdev *led_cdev)
> if (IS_ERR_OR_NULL(led_cdev->dev))
> return;
>
> + led_cdev->flags |= LED_UNREGISTERING;
[Severity: High]
This is a pre-existing issue, but does relying on a non-atomic update to
flags here fail to prevent the race condition?
Because led_cdev->flags is updated non-atomically via a read-modify-write
operation, concurrent modifications to flags can overwrite and drop the
LED_UNREGISTERING bit.
For example, if a user-space thread writes to the LED's trigger sysfs
attribute to remove a trigger concurrently, __led_trigger_set() modifies
the flags locklessly:
drivers/leds/led-triggers.c:__led_trigger_set() {
...
led_cdev->flags &= ~LED_INIT_DEFAULT_TRIGGER;
...
}
If this overwrites the LED_UNREGISTERING flag, the new early-exit check
introduced in this patch:
drivers/leds/led-triggers.c:__led_trigger_set() {
if ((led_cdev->flags & LED_UNREGISTERING) && trig)
return -ENODEV;
...
will falsely pass. This still allows a trigger to attach to the dying LED,
potentially resulting in a use-after-free.
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260802-leds-trigger-hw-changed-v4-0-f97e2ca976fe@rong.moe?part=8
next prev parent reply other threads:[~2026-08-02 17:31 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-01 17:26 [PATCH v4 00/12] leds: Add support for hardware-initiated hardware control trigger transition Rong Zhang
2026-08-01 17:26 ` [PATCH v4 01/12] leds: Move led_trigger_is_hw_controlled() to the right place Rong Zhang
2026-08-02 17:31 ` sashiko-bot
2026-08-01 17:26 ` [PATCH v4 02/12] leds: class: Remove hardware control trigger when writing brightness Rong Zhang
2026-08-02 17:31 ` sashiko-bot
2026-08-01 17:26 ` [PATCH v4 03/12] leds: trigger: Add offloaded() callback and provide trigger_may_offload attribute Rong Zhang
2026-08-02 17:31 ` sashiko-bot
2026-08-01 17:26 ` [PATCH v4 04/12] leds: cros_ec: Implement offloaded() trigger callback Rong Zhang
2026-08-02 17:31 ` sashiko-bot
2026-08-01 17:26 ` [PATCH v4 05/12] leds: turris-omnia: Implement offloaded() trigger callback and declare hw_control_trigger Rong Zhang
2026-08-02 17:31 ` sashiko-bot
2026-08-01 17:26 ` [PATCH v4 06/12] leds: trigger: netdev: Implement offloaded() callback Rong Zhang
2026-08-02 17:31 ` sashiko-bot
2026-08-01 17:26 ` [PATCH v4 07/12] leds: trigger: Enforce strict checks in led_trigger_is_hw_controlled() Rong Zhang
2026-08-02 17:31 ` sashiko-bot
2026-08-01 17:26 ` [PATCH v4 08/12] leds: trigger: Do not attach trigger to a removing LED Rong Zhang
2026-08-02 17:31 ` sashiko-bot [this message]
2026-08-01 17:26 ` [PATCH v4 09/12] leds: trigger: Add led_trigger_notify_hw_control_changed() interface Rong Zhang
2026-08-02 17:31 ` sashiko-bot
2026-08-01 17:26 ` [PATCH v4 10/12] platform/x86: ideapad-laptop: Decouple hardware & classdev brightness for keyboard backlight Rong Zhang
2026-08-02 17:31 ` sashiko-bot
2026-08-01 17:26 ` [PATCH v4 11/12] platform/x86: ideapad-laptop: Serialize keyboard backlight notifications Rong Zhang
2026-08-02 17:31 ` sashiko-bot
2026-08-01 17:26 ` [PATCH v4 12/12] platform/x86: ideapad-laptop: Fully support auto keyboard backlight Rong Zhang
2026-08-02 17:31 ` sashiko-bot
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=20260802173150.F31FB1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=i@rong.moe \
--cc=lee@kernel.org \
--cc=linux-leds@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox