CVE-2026-23188: Linux Kernel r8152 Driver DoS Vulnerability

CVE-2026-23188 Overview

A deadlock vulnerability has been identified in the Linux kernel's Realtek r8152 USB network driver. The vulnerability occurs during device resume operations where the rtl8152_resume function can trigger a device reset while holding the tp->control mutex, leading to a recursive mutex lock attempt that causes a system deadlock.

Critical Impact

This vulnerability can cause complete system hangs during USB device resume operations, potentially leading to kernel panic and requiring a system reboot to recover.

Affected Products

• Linux kernel with r8152 USB network driver
• Systems using Realtek RTL8152/RTL8153 USB Ethernet adapters
• Devices utilizing USB network interfaces with affected kernel versions

Discovery Timeline

• 2026-02-14 - CVE CVE-2026-23188 published to NVD
• 2026-02-18 - Last updated in NVD database

Technical Details for CVE-2026-23188

Vulnerability Analysis

This deadlock vulnerability exists within the Realtek r8152 USB network driver subsystem of the Linux kernel. The flaw manifests when the driver attempts to resume from a suspended state and encounters a condition requiring a device reset. The core issue lies in the improper synchronization of mutex operations during the resume-reset sequence.

When rtl8152_resume is invoked during USB device wake-up, it acquires the tp->control mutex to perform necessary operations. If the device is in an inaccessible state requiring a reset, the function calls usb_reset_device(). This reset operation subsequently triggers rtl8152_post_reset, which then attempts to call __rtl8152_set_mac_address. This function attempts to acquire the same tp->control mutex that is already held by the calling thread, resulting in a classic recursive deadlock condition.

The call trace provided in the kernel logs demonstrates the deadlock path, showing the scheduler being invoked while waiting for the mutex lock, which never becomes available because the same thread already holds it. After approximately 10 seconds, the Device Power Management (DPM) subsystem times out, and the system will panic within 15 seconds if the deadlock is not resolved.

Root Cause

The root cause is a recursive mutex acquisition attempt in the r8152 driver's resume path. The rtl8152_resume function holds tp->control mutex while calling code paths that attempt to reacquire the same lock. Specifically, the reset operation executed under the mutex scope re-enters the driver through rtl8152_post_reset and dev_set_mac_address, which requires the same mutex. This violates the non-reentrant nature of standard mutex implementations in the Linux kernel.

Attack Vector

The vulnerability is triggered through normal system operations rather than malicious input. Any scenario that causes a USB suspend/resume cycle on an RTL8152/RTL8153 USB network adapter where the device becomes inaccessible can trigger this deadlock. This includes:

• System sleep/wake cycles (suspend to RAM or hibernate)
• USB port power management operations
• USB hub resets or hotplug events
• Driver unbind/rebind operations during certain timing windows

The attack vector is local and requires the affected USB network driver to be in use. While not directly exploitable for code execution, the denial of service impact can be severe in production environments where system availability is critical.

Detection Methods for CVE-2026-23188

Indicators of Compromise

• System hangs occurring during USB device resume operations with RTL8152/RTL8153 adapters
• Kernel log messages showing "DPM device timeout after 10 seconds" followed by panic warnings
• Stack traces in dmesg showing __mutex_lock_common called from rtl8152_post_reset within rtl8152_resume context
• Unresponsive systems after waking from sleep with USB network adapters connected

Detection Strategies

• Monitor kernel logs for DPM timeout warnings associated with USB network device resume operations
• Implement watchdog timers to detect system hangs during power state transitions
• Deploy kernel tracing with ftrace to monitor mutex contention in the r8152 driver
• Use hardware watchdog mechanisms to automatically recover from deadlock conditions

Monitoring Recommendations

• Configure system logging to capture kernel mutex debugging output when r8152 driver is loaded
• Enable CONFIG_LOCKDEP on development/test systems to proactively detect potential deadlock scenarios
• Monitor system uptime and power management event completion times for anomalies
• Implement automated testing of suspend/resume cycles on systems with affected USB network adapters

How to Mitigate CVE-2026-23188

Immediate Actions Required

• Update to a patched Linux kernel version that includes the fix for this vulnerability
• Consider disabling USB autosuspend for RTL8152/RTL8153 devices as a temporary workaround
• On critical systems, consider using alternative network interfaces until patching is completed
• Review system power management policies for USB network devices

Patch Information

The Linux kernel development team has released patches addressing this deadlock vulnerability. The fix moves the reset operation for inaccessible devices outside of the tp->control mutex scope, preventing the recursive mutex acquisition scenario.

Patches are available through the following kernel git commits:

• Kernel Git Commit 1b2efc5
• Kernel Git Commit 61c8091
• Kernel Git Commit 6d06bc83

Organizations should apply the appropriate patch for their kernel version through their distribution's package management system or by building an updated kernel from source.

Workarounds

• Disable USB autosuspend for the r8152 device to prevent the problematic resume path from being triggered
• Use udev rules to set power management to "on" for affected USB network adapters
• Configure systems to avoid suspend states when USB network connectivity is critical
• Deploy hardware watchdog timers to automatically reboot systems if they become unresponsive

# Disable USB autosuspend for RTL8152/RTL8153 devices
# Add to /etc/udev/rules.d/50-r8152-power.rules
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="0bda", ATTR{idProduct}=="8152", ATTR{power/control}="on"
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="0bda", ATTR{idProduct}=="8153", ATTR{power/control}="on"

# Reload udev rules after creating the file
udevadm control --reload-rules
udevadm trigger