linux-kernel - [PATCH v2] leds: triggers: flush pending brightness before activating trigger

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20240613-led-trigger-flush-v2-1-f4f970799d77@weissschuh.net>
Date: Thu, 13 Jun 2024 17:24:51 +0200
From: Thomas Weißschuh <linux@...ssschuh.net>
To: Pavel Machek <pavel@....cz>, Lee Jones <lee@...nel.org>, 
 Jacek Anaszewski <jacek.anaszewski@...il.com>
Cc: linux-leds@...r.kernel.org, linux-kernel@...r.kernel.org, 
 Dustin Howett <dustin@...ett.net>, stable@...r.kernel.org, 
 Thomas Weißschuh <linux@...ssschuh.net>
Subject: [PATCH v2] leds: triggers: flush pending brightness before
 activating trigger

The race fixed in timer_trig_activate() between a blocking
set_brightness() call and trigger->activate() can affect any trigger.
So move the call to flush_work() into led_trigger_set() where it can
avoid the race for all triggers.

Fixes: 0db37915d912 ("leds: avoid races with workqueue")
Fixes: 8c0f693c6eff ("leds: avoid flush_work in atomic context")
Cc: stable@...r.kernel.org
Tested-by: Dustin L. Howett <dustin@...ett.net>
Signed-off-by: Thomas Weißschuh <linux@...ssschuh.net>
---
Changes in v2:
- Cc stable
- Add Dustin's Tested-by
- Rebase against led/for-leds-next
- Always execute flush_work(), similar to synchronize_rcu()
- Link to v1: https://lore.kernel.org/r/20240603-led-trigger-flush-v1-1-c904c6e2fb34@weissschuh.net
---

Commit 7abae7a11fc9 ("leds: trigger: Call synchronize_rcu() before calling trig->activate()")
alone also solves the issue that the LED stays completely off after
enabling the trigger.
But there is a recognizable timeframe where it is disabled in between.

Also from a correctness perspective, this seems like a coincidence and
the call to flush_work() is the correct fix for that race.
---
 drivers/leds/led-triggers.c          | 6 ++++++
 drivers/leds/trigger/ledtrig-timer.c | 5 -----
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/leds/led-triggers.c b/drivers/leds/led-triggers.c
index 59deadb86335..78eb20093b2c 100644
--- a/drivers/leds/led-triggers.c
+++ b/drivers/leds/led-triggers.c
@@ -201,6 +201,12 @@ int led_trigger_set(struct led_classdev *led_cdev, struct led_trigger *trig)
 		 */
 		synchronize_rcu();
 
+		/*
+		 * If "set brightness to 0" is pending in workqueue,
+		 * we don't want that to be reordered after ->activate()
+		 */
+		flush_work(&led_cdev->set_brightness_work);
+
 		ret = 0;
 		if (trig->activate)
 			ret = trig->activate(led_cdev);
diff --git a/drivers/leds/trigger/ledtrig-timer.c b/drivers/leds/trigger/ledtrig-timer.c
index b4688d1d9d2b..1d213c999d40 100644
--- a/drivers/leds/trigger/ledtrig-timer.c
+++ b/drivers/leds/trigger/ledtrig-timer.c
@@ -110,11 +110,6 @@ static int timer_trig_activate(struct led_classdev *led_cdev)
 		led_cdev->flags &= ~LED_INIT_DEFAULT_TRIGGER;
 	}
 
-	/*
-	 * If "set brightness to 0" is pending in workqueue, we don't
-	 * want that to be reordered after blink_set()
-	 */
-	flush_work(&led_cdev->set_brightness_work);
 	led_blink_set(led_cdev, &led_cdev->blink_delay_on,
 		      &led_cdev->blink_delay_off);
 

---
base-commit: 005408af25d5550e1bd22a18bf371651969c17ee
change-id: 20240603-led-trigger-flush-3bef303eb902

Best regards,
-- 
Thomas Weißschuh <linux@...ssschuh.net>