In the Linux kernel, the following vulnerability has been resolved: leds: led-class: Only Add LED to ledslist when it is fully ready Before this change the LED was added to ledslist before ledinitcore() gets called adding it the list before ledclassdev.setbrightnesswork gets initialized. This leaves a window where ledtriggerregister() of a LED's default trigger will call ledtriggerset() which calls ledsetbrightness() which in turn will end up queueing the *uninitialized* ledclassdev.setbrightnesswork. This race gets hit by the lenovo-thinkpad-t14s EC driver which registers 2 LEDs with a default trigger provided by sndctlled.ko in quick succession. The first ledclassdevregister() causes an async modprobe of sndctlled to run and that async modprobe manages to exactly hit the window where the second LED is on the ledslist without ledinitcore() being called for it, resulting in: ------------[ cut here ]------------ WARNING: CPU: 11 PID: 5608 at kernel/workqueue.c:4234 _flushwork+0x344/0x390 Hardware name: LENOVO 21N2S01F0B/21N2S01F0B, BIOS N42ET93W (2.23 ) 09/01/2025 ... Call trace: _flushwork+0x344/0x390 (P) flushwork+0x2c/0x50 ledtriggerset+0x1c8/0x340 ledtriggerregister+0x17c/0x1c0 ledtriggerregistersimple+0x84/0xe8 sndctlledinit+0x40/0xf88 [sndctlled] dooneinitcall+0x5c/0x318 doinitmodule+0x9c/0x2b8 loadmodule+0x7e0/0x998 Close the race window by moving the adding of the LED to ledslist to after the ledinitcore() call.