All of lore.kernel.org
 help / color / mirror / Atom feed
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

  reply	other threads:[~2026-08-02 17:31 UTC|newest]

Thread overview: 26+ 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-11 19:13     ` Lee Jones
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 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.