CVE-2026-23357 in Linux
Summary
by MITRE • 03/25/2026
In the Linux kernel, the following vulnerability has been resolved:
can: mcp251x: fix deadlock in error path of mcp251x_open
The mcp251x_open() function call free_irq() in its error path with the mpc_lock mutex held. But if an interrupt already occurred the interrupt handler will be waiting for the mpc_lock and free_irq() will deadlock waiting for the handler to finish.
This issue is similar to the one fixed in commit 7dd9c26bd6cf ("can: mcp251x: fix deadlock if an interrupt occurs during mcp251x_open") but for the error path.
To solve this issue move the call to free_irq() after the lock is released. Setting `priv->force_quit = 1` beforehand ensure that the IRQ handler will exit right away once it acquired the lock.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 05/04/2026
The vulnerability described in CVE-2026-23357 represents a critical deadlock condition within the Linux kernel's CAN (Controller Area Network) subsystem, specifically affecting the mcp251x driver implementation. This issue manifests during the error handling path of the mcp251x_open() function, where improper locking mechanisms create a circular dependency that prevents system operation. The mcp251x driver is responsible for managing Microchip MCP251x series CAN controllers, which are widely deployed in automotive and industrial applications for real-time communication between embedded systems. The vulnerability directly impacts the kernel's ability to properly handle device initialization failures, creating a potential system hang condition that could affect mission-critical applications.
The technical flaw stems from a fundamental race condition in the driver's error handling mechanism where the function attempts to release interrupt resources while holding a mutex lock that the interrupt handler simultaneously requires. Specifically, when mcp251x_open() encounters an error condition, it calls free_irq() while the mpc_lock mutex remains acquired. However, if an interrupt has already occurred and is pending execution, the interrupt handler will block waiting for the same mutex that the error path is holding. This creates a classic deadlock scenario where free_irq() waits for the interrupt handler to complete, while the interrupt handler waits for the mutex to be released, resulting in a system-wide hang condition that can persist until manual intervention occurs.
The operational impact of this vulnerability extends beyond simple system hangs to encompass potential safety-critical failures in automotive and industrial environments where CAN communication is essential. The issue affects systems using MCP251x CAN controllers, which are prevalent in vehicle networks, industrial automation, and embedded control systems where reliable communication is paramount. When this deadlock occurs during device initialization, it prevents proper resource cleanup and can lead to complete system unresponsiveness, potentially causing vehicle malfunctions, industrial process failures, or other critical system interruptions that could result in financial loss or safety hazards. The vulnerability is particularly concerning because it occurs during the device open operation, which is a fundamental system function that should never cause system-wide failures.
The mitigation strategy for this vulnerability involves a carefully orchestrated sequence of operations that breaks the deadlock condition through proper lock ordering and interrupt handling. The solution requires moving the free_irq() call to occur after the mutex lock is released, while setting a force_quit flag beforehand to ensure the interrupt handler terminates immediately upon acquiring the lock. This approach aligns with established best practices for interrupt handling in kernel space and addresses the specific conditions outlined in the CWE-362 category for concurrent execution issues. The fix demonstrates proper understanding of the ATT&CK framework's system compromise tactics, particularly in preventing privilege escalation through kernel-level race conditions. The implementation follows standard kernel development practices for handling interrupt cleanup operations, ensuring that resource management operations do not create circular dependencies that could compromise system stability. This vulnerability resolution exemplifies the importance of careful lock management in kernel drivers and highlights the critical need for thorough testing of error paths in real-time embedded systems where interrupt handling and resource management must be carefully coordinated to maintain system reliability.