CVE-2026-23368: Linux Kernel Race Condition Vulnerability

CVE-2026-23368 Overview

A deadlock vulnerability has been identified in the Linux kernel affecting the PHY LED trigger subsystem. The flaw occurs when both LEDS_TRIGGER_NETDEV and LED_TRIGGER_PHY kernel configuration options are enabled simultaneously. An AB-BA deadlock condition arises due to improper lock ordering between triggers_list_lock and rtnl_mutex during PHY attachment and LED trigger activation operations.

Critical Impact

This vulnerability can cause system hangs and denial of service conditions when LED triggers are registered during PHY device attachment, potentially affecting network availability on affected Linux systems.

Affected Products

• Linux kernel with LED_TRIGGER_PHY enabled
• Linux kernel with LEDS_TRIGGER_NETDEV enabled
• Systems using MediaTek network drivers (mtk_open)

Discovery Timeline

• 2026-03-25 - CVE CVE-2026-23368 published to NVD
• 2026-03-25 - Last updated in NVD database

Technical Details for CVE-2026-23368

Vulnerability Analysis

The vulnerability represents a classic AB-BA deadlock scenario in the Linux kernel's network PHY subsystem. The deadlock occurs due to inconsistent lock acquisition ordering between two different code paths:

In the first path, LED_TRIGGER_PHY registers LED triggers during phy_attach_direct() while already holding the rtnl_mutex (acquired via dev_ioctl()). The code then attempts to acquire triggers_list_lock through led_trigger_register().

In the second path, LEDS_TRIGGER_NETDEV activation first acquires triggers_list_lock via led_trigger_set(), then attempts to acquire rtnl_mutex through register_netdevice_notifier() called from netdev_trig_activate().

This creates a circular dependency where each path holds one lock while waiting for the other, resulting in a permanent deadlock condition that can freeze the affected system.

Root Cause

The root cause is the placement of phy_led_triggers_register() within the phy_attach_direct() function, which executes while the RTNL lock is held. The PHY LED trigger registration does not actually require RTNL protection as it does not interact with the network stack in a way that needs this synchronization. Additionally, there is no requirement for the PHY to be attached to a MAC controller before registering triggers, as the triggers only utilize phydev state information.

Attack Vector

The deadlock can be triggered through normal system operation when:

1. A user or application enables the netdev LED trigger on any LED device (Path B - acquires triggers_list_lock first)
2. Simultaneously, a network interface is being brought up or a PHY device is being attached (Path A - acquires rtnl_mutex first)

This is not a remotely exploitable vulnerability but represents a local denial of service condition that can occur during normal system operation. The deadlock manifests when network device ioctl operations and LED trigger sysfs writes occur concurrently.

The kernel stack traces reveal the deadlock occurring through the mtk_open() function in the MediaTek ethernet driver, though any driver using phylink_fwnode_phy_connect() with PHY LED triggers enabled would be susceptible.

Detection Methods for CVE-2026-23368

Indicators of Compromise

• System becomes unresponsive during network interface initialization
• Kernel log messages showing hung task warnings related to led_trigger_register or phy_attach_direct
• Processes blocked in D (uninterruptible sleep) state waiting on rtnl_mutex or triggers_list_lock
• Network interfaces failing to come up with extended timeouts

Detection Strategies

• Monitor system logs for hung task warnings mentioning PHY or LED subsystems
• Use lockdep kernel debugging feature to detect lock ordering violations
• Monitor /proc/lockdep_chains for circular lock dependencies
• Deploy kernel probes on led_trigger_register() and phy_led_triggers_register() to detect contention

Monitoring Recommendations

• Enable CONFIG_LOCKDEP in development environments to proactively detect lock ordering issues
• Monitor for extended D-state processes using tools like ps or process accounting
• Implement watchdog monitoring for network interface bring-up operations
• Review kernel logs regularly for INFO: task blocked messages

How to Mitigate CVE-2026-23368

Immediate Actions Required

• Apply the kernel patches from the stable kernel tree
• Disable LED_TRIGGER_PHY configuration option if PHY LED triggers are not required
• Avoid concurrent LED trigger configuration changes during network interface operations
• Consider temporarily disabling LEDS_TRIGGER_NETDEV until patches are applied

Patch Information

The Linux kernel development team has resolved this vulnerability by moving the phy_led_triggers_register() call to the PHY probe and release functions, which do not hold the RTNL lock. Multiple patch commits have been released across stable kernel branches:

• Commit 241cd64cf2e3
• Commit 2764dcb3c35d
• Commit c33523b8fd2d
• Commit c6ffc2d2338d
• Commit c8dbdc6e380e
• Commit cde2d0b5ab5d

Workarounds

• Disable PHY LED triggers by setting CONFIG_LED_TRIGGER_PHY=n in kernel configuration
• Serialize network interface operations and LED trigger configuration changes
• Use udev rules to delay LED trigger configuration until after network initialization completes

# Configuration example
# Disable PHY LED triggers in kernel config
echo "CONFIG_LED_TRIGGER_PHY=n" >> /path/to/kernel/.config

# Alternatively, prevent concurrent access via systemd ordering
# /etc/systemd/system/network-led.service.d/override.conf
# [Unit]
# After=network.target