Re: [PATCH v4 08/12] leds: trigger: Do not attach trigger to a removing LED
[email protected] Sun, 02 Aug 2026 17:31:49 +0000
| Newsgroups | org.kernel.vger.linux-leds |
|---|---|
| Message-ID | <[email protected]> |
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 r= emoving LED --- commit dd467951eb46d9ac1296845c072ca12344efe3da Author: Rong Zhang <[email protected]> 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; > =20 > + led_cdev->flags |=3D LED_UNREGISTERING; [Severity: High] This is a pre-existing issue, but does relying on a non-atomic update to=20 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 &=3D ~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. [ ... ] --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260802-leds-trigg= [email protected]?part=3D8