CVE-2026-23101
Unknown Unknown - Not Provided
Race Condition in Linux Kernel LED Class Causing Workqueue Crash

Publication date: 2026-02-04

Last updated on: 2026-03-19

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: leds: led-class: Only Add LED to leds_list when it is fully ready Before this change the LED was added to leds_list before led_init_core() gets called adding it the list before led_classdev.set_brightness_work gets initialized. This leaves a window where led_trigger_register() of a LED's default trigger will call led_trigger_set() which calls led_set_brightness() which in turn will end up queueing the *uninitialized* led_classdev.set_brightness_work. This race gets hit by the lenovo-thinkpad-t14s EC driver which registers 2 LEDs with a default trigger provided by snd_ctl_led.ko in quick succession. The first led_classdev_register() causes an async modprobe of snd_ctl_led to run and that async modprobe manages to exactly hit the window where the second LED is on the leds_list without led_init_core() being called for it, resulting in: ------------[ cut here ]------------ WARNING: CPU: 11 PID: 5608 at kernel/workqueue.c:4234 __flush_work+0x344/0x390 Hardware name: LENOVO 21N2S01F0B/21N2S01F0B, BIOS N42ET93W (2.23 ) 09/01/2025 ... Call trace: __flush_work+0x344/0x390 (P) flush_work+0x2c/0x50 led_trigger_set+0x1c8/0x340 led_trigger_register+0x17c/0x1c0 led_trigger_register_simple+0x84/0xe8 snd_ctl_led_init+0x40/0xf88 [snd_ctl_led] do_one_initcall+0x5c/0x318 do_init_module+0x9c/0x2b8 load_module+0x7e0/0x998 Close the race window by moving the adding of the LED to leds_list to after the led_init_core() call.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-02-04
Last Modified
2026-03-19
Generated
2026-05-07
AI Q&A
2026-02-04
EPSS Evaluated
2026-05-05
NVD
Affected Vendors & Products
Showing 12 associated CPEs
Vendor Product Version / Range
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel From 5.11 (inc) to 5.15.199 (exc)
linux linux_kernel From 5.16 (inc) to 6.1.162 (exc)
linux linux_kernel From 6.2 (inc) to 6.6.122 (exc)
linux linux_kernel From 6.7 (inc) to 6.12.68 (exc)
linux linux_kernel From 6.13 (inc) to 6.18.8 (exc)
linux linux_kernel 6.19
linux linux_kernel From 3.7 (inc) to 5.10.249 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-908 The product uses or accesses a resource that has not been initialized.
Attack-Flow Graph
AI Powered Q&A
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

I don't know


Can you explain this vulnerability to me?

This vulnerability is a race condition in the Linux kernel's LED subsystem. Specifically, an LED device was being added to the leds_list before it was fully initialized by the led_init_core() function. This premature addition allowed the LED's default trigger to call functions that operated on an uninitialized work structure (set_brightness_work), leading to potential kernel warnings or crashes.

The issue was triggered by the lenovo-thinkpad-t14s EC driver which registers two LEDs with a default trigger in quick succession. The asynchronous loading of the snd_ctl_led module could hit the timing window where the second LED was on the leds_list but not fully initialized, causing a kernel warning and instability.

The fix involved moving the addition of the LED to the leds_list until after the led_init_core() function completes, closing the race window.


How can this vulnerability impact me? :

This vulnerability can cause kernel warnings and potentially system instability or crashes due to the race condition in LED initialization. Systems using affected drivers, such as the lenovo-thinkpad-t14s EC driver, may experience unexpected behavior or reliability issues when the LED subsystem triggers work on uninitialized structures.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability manifests as a race condition in the Linux kernel's LED subsystem, which can cause warnings or errors related to workqueue flushing and LED trigger registration.

Detection can involve monitoring kernel logs for warning messages similar to the following:

  • WARNING: CPU: ... at kernel/workqueue.c:4234 __flush_work+0x344/0x390
  • Call trace entries involving led_trigger_set, led_trigger_register, snd_ctl_led_init, and load_module

You can check kernel logs using commands like:

  • dmesg | grep -i 'led_trigger_set'
  • journalctl -k | grep -i 'flush_work'
  • journalctl -k | grep -i 'snd_ctl_led'

Additionally, reviewing the presence and initialization order of LED devices and their triggers in the system may help identify if the vulnerable code path is exercised.


What immediate steps should I take to mitigate this vulnerability?

The vulnerability is resolved by ensuring that LEDs are only added to the leds_list after their core initialization (led_init_core) is complete, preventing the race condition.

Immediate mitigation steps include:

  • Update the Linux kernel to a version that includes the fix where the LED is added to leds_list only after led_init_core() is called.
  • If updating the kernel is not immediately possible, consider disabling or unloading the snd_ctl_led module or any related LED triggers that may trigger this race condition.
  • Monitor kernel logs for related warnings to detect if the issue is occurring.

Ultimately, applying the official patch or upgrading to a fixed kernel version is the recommended and most effective mitigation.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart