CVE-2026-23101: Linux Kernel Race Condition Vulnerability

CVE-2026-23101 Overview

CVE-2026-23101 is a race condition vulnerability in the Linux kernel's LED class subsystem. The vulnerability exists in the led-class component where an LED device is added to the leds_list before led_init_core() completes initialization, specifically before led_classdev.set_brightness_work is properly initialized.

This premature list addition creates a race window where led_trigger_register() of a LED's default trigger can call led_trigger_set(), which in turn calls led_set_brightness(), ultimately queuing an uninitialized work structure. This can result in system warnings and potential instability.

Critical Impact

Race condition in Linux kernel LED subsystem can cause kernel warnings and system instability when LED devices with default triggers are registered in quick succession.

Affected Products

• Linux Kernel (LED class subsystem)
• Systems using Lenovo ThinkPad T14s EC driver with LED triggers
• Systems using snd_ctl_led.ko module with LED devices

Discovery Timeline

• February 4, 2026 - CVE CVE-2026-23101 published to NVD
• February 5, 2026 - Last updated in NVD database

Technical Details for CVE-2026-23101

Vulnerability Analysis

The vulnerability is a classic race condition in the Linux kernel's LED class registration process. When led_classdev_register() is called, the LED device was being added to the global leds_list before led_init_core() had completed initialization of the device's internal work structures.

The race condition becomes exploitable when multiple LEDs are registered rapidly, particularly when those LEDs have default triggers associated with them. The first LED registration triggers an asynchronous module probe (for example, of snd_ctl_led.ko), and if that async operation completes while a second LED is being registered, it can attempt to interact with the partially initialized second LED.

The kernel warning stack trace reveals the issue manifests in __flush_work() when attempting to flush an uninitialized work structure, triggered through the call chain: led_trigger_register() → led_trigger_set() → led_set_brightness().

Root Cause

The root cause is improper synchronization in the LED class registration sequence. The LED device was added to leds_list too early in the initialization process—before led_init_core() had initialized the set_brightness_work work queue structure. This violates the principle that shared data structures should only be made visible to other threads after they are fully initialized.

Attack Vector

This vulnerability is triggered locally through normal system operations rather than requiring explicit attacker action. The race condition is hit naturally when:

1. An EC driver (such as the Lenovo ThinkPad T14s driver) registers multiple LEDs with default triggers in quick succession
2. The first LED registration triggers an async module load of the trigger module (e.g., snd_ctl_led.ko)
3. The async module initialization completes and iterates through leds_list while the second LED is still partially initialized
4. The trigger code attempts to set brightness on the uninitialized LED, causing a kernel warning

The vulnerability was observed with the following kernel warning output in affected systems, demonstrating the uninitialized work queue being flushed during led_trigger_set() operations.

Detection Methods for CVE-2026-23101

Indicators of Compromise

• Kernel warnings in system logs referencing __flush_work at offset +0x344/0x390
• Stack traces showing led_trigger_set → led_trigger_register call chain
• Warnings occurring during snd_ctl_led module initialization
• System instability during boot on affected Lenovo ThinkPad T14s systems or similar hardware with dual LED configurations

Detection Strategies

• Monitor kernel message buffers (dmesg) for WARNING: CPU: messages referencing kernel/workqueue.c and led_trigger_set
• Implement log monitoring for kernel oops or warnings during boot sequence involving LED subsystem
• Use kernel tracing (ftrace) to monitor led_classdev_register() and led_trigger_register() function calls for timing anomalies

Monitoring Recommendations

• Enable kernel warning logging and configure alerting for LED subsystem-related warnings
• Monitor system stability on hardware with multiple LED devices and default triggers
• Review boot logs on ThinkPad T14s and similar systems after kernel updates
• Consider using CONFIG_DEBUG_OBJECTS kernel option to detect uninitialized work structures in testing environments

How to Mitigate CVE-2026-23101

Immediate Actions Required

• Update to a patched Linux kernel version that includes the fix commits
• Review and apply the kernel patches from the official kernel git repository
• Test system stability after applying patches, particularly on affected hardware platforms
• Monitor systems for kernel warnings during the patching window

Patch Information

The fix addresses the race condition by moving the addition of the LED to leds_list to after the led_init_core() call completes. This ensures the LED device is fully initialized before it becomes visible to other kernel subsystems.

Multiple patch commits are available:

• Kernel Git Commit #2757f77
• Kernel Git Commit #7882262
• Kernel Git Commit #d1883cef
• Kernel Git Commit #da565bf

Workarounds

• Delay LED trigger module loading by blacklisting snd_ctl_led and loading it manually after system boot completes
• If experiencing issues, disable automatic LED trigger loading via kernel module parameters
• Consider compiling LED-related drivers as modules rather than built-in to control loading order
• For critical systems, avoid rapid successive LED device registrations until patched kernel is deployed

# Temporary workaround: Blacklist snd_ctl_led module during boot
echo "blacklist snd_ctl_led" >> /etc/modprobe.d/led-race-workaround.conf

# Load the module manually after boot completes
modprobe snd_ctl_led