CVE-2026-23357: Linux Kernel Race Condition Vulnerability

CVE-2026-23357 Overview

A deadlock vulnerability has been identified in the Linux kernel's MCP251x CAN (Controller Area Network) driver. The vulnerability exists in the mcp251x_open() function's error path, where free_irq() is called while still holding the mpc_lock mutex. If an interrupt occurs during this window, the interrupt handler will attempt to acquire the same mutex, creating a deadlock condition where free_irq() waits indefinitely for the handler to complete while the handler waits for the lock.

This issue is analogous to a previously fixed vulnerability addressed in commit 7dd9c26bd6cf ("can: mcp251x: fix deadlock if an interrupt occurs during mcp251x_open"), but affects the error handling path rather than the normal execution flow.

Critical Impact
Systems using MCP251x CAN controllers may experience kernel deadlocks, causing complete system hangs requiring a hard reboot. This is particularly concerning for embedded systems and industrial applications relying on CAN bus communication.

Affected Products

Linux kernel with MCP251x CAN driver enabled
Systems using MCP2510 or MCP2515 CAN controllers
Embedded Linux devices with CAN bus interfaces

Discovery Timeline

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

Technical Details for CVE-2026-23357

Vulnerability Analysis

The deadlock vulnerability occurs due to improper mutex handling in the error path of the mcp251x_open() function within the Linux kernel's CAN driver for MCP251x chips. When the function encounters an error condition after successfully registering an interrupt handler, it attempts to clean up by calling free_irq(). However, this call is made while the mpc_lock mutex is still held.

The deadlock manifests when an interrupt fires between the time the IRQ handler is registered and when free_irq() is called in the error path. The IRQ handler routine attempts to acquire mpc_lock to safely access shared resources. Since the main thread holds this lock while waiting for free_irq() to complete—which itself is blocked waiting for the IRQ handler to finish—a classic circular wait deadlock occurs.

Root Cause

The root cause is a lock ordering violation in the error handling code path. The mpc_lock mutex protects shared state between the main driver code and the interrupt handler. When free_irq() is called, it must wait for any in-flight interrupt handlers to complete before returning. If the interrupt handler is blocked waiting for mpc_lock (held by the caller of free_irq()), neither can proceed.

The fix involves restructuring the error path to release the mpc_lock mutex before calling free_irq(), while setting priv->force_quit = 1 to signal the IRQ handler to exit immediately once it acquires the lock.

Attack Vector

This vulnerability is primarily a reliability and availability issue rather than a security exploitation vector. The deadlock condition can be triggered under the following circumstances:

The vulnerability requires local access to a system with an MCP251x CAN controller. An attacker or fault condition that causes errors during the CAN interface initialization (via mcp251x_open()) combined with interrupt activity can trigger the deadlock. While not directly exploitable for code execution, the resulting system hang constitutes a denial of service condition.

In embedded systems or industrial control environments where CAN bus communication is critical, this deadlock could have significant operational impact, potentially affecting safety-critical systems.

Detection Methods for CVE-2026-23357

Indicators of Compromise

System hangs or freezes when initializing MCP251x CAN interfaces
Kernel soft lockup warnings in system logs referencing mcp251x or CAN driver functions
Unresponsive systems that correlate with CAN interface bring-up attempts
Stack traces showing mcp251x_open and free_irq in locked state

Detection Strategies

Monitor kernel logs for soft lockup or hung task warnings involving the mcp251x module
Implement kernel watchdog monitoring to detect and alert on system hangs
Use kernel tracing tools (ftrace, perf) to monitor mutex contention in CAN driver paths
Review crash dumps for call stacks involving mcp251x_open() error handling

Monitoring Recommendations

Enable kernel watchdog functionality to detect and recover from soft lockups
Configure system monitoring to alert on CAN interface initialization failures
Deploy logging for CAN subsystem events to track error conditions
Consider implementing automated recovery mechanisms for embedded systems

How to Mitigate CVE-2026-23357

Immediate Actions Required

Update the Linux kernel to a patched version containing the fix
Review systems using MCP251x CAN controllers for potential exposure
Implement kernel watchdog timers as a recovery mechanism for affected systems
Consider temporarily disabling automatic CAN interface initialization until patched

Patch Information

The Linux kernel development team has released patches to address this vulnerability across multiple kernel branches. The fix moves the free_irq() call to after the mutex is released and sets priv->force_quit = 1 beforehand to ensure the IRQ handler exits cleanly once it acquires the lock.

Patches are available via the following kernel git commits:

Workarounds

Enable hardware watchdog timers to automatically reboot systems that experience deadlocks
Reduce CAN interface initialization retries to minimize exposure windows
Implement process supervision to detect and restart hung CAN-dependent services
Consider using alternative CAN controller hardware if patches cannot be immediately applied

bash

# Check if MCP251x driver is loaded and verify kernel version
lsmod | grep mcp251x
uname -r

# Monitor kernel logs for CAN-related issues
dmesg | grep -i "mcp251x\|can\|lockup"

# Enable kernel watchdog for deadlock recovery
echo 60 > /proc/sys/kernel/watchdog_thresh