CVE-2026-23357

What it actually does

Race condition in mcp251x_open error path causes deadlock: free_irq() is invoked while mpc_lock is held, allowing a pending interrupt handler to block indefinitely waiting for the same mutex.

Why it matters to the business

Systems using MCP251x CAN controllers may experience kernel hangs or forced reboots during device initialization under load or error conditions, leading to loss of availability for affected hardware and dependent applications.

How an attack unfolds

A local attacker triggers the error path inside mcp251x_open (for example by causing an open failure after the IRQ is requested) while an interrupt is already pending; the handler then waits for mpc_lock, producing a deadlock when free_irq attempts to synchronize with the handler.

How to fix it

Apply the upstream fix that sets priv->force_quit = 1 before releasing mpc_lock and moves the free_irq call to after the mutex is dropped; rebuild and deploy the corrected kernel on all affected systems.

How to confirm the fix worked

Inspect the mcp251x_open function in the driver source to confirm free_irq is invoked only after the mutex release and that force_quit is set on the error path; test device open/close sequences under interrupt load to verify absence of deadlock.

Typical attack path

1. Local user or process initiates mcp251x device open
2. Open enters error path after IRQ registration but before lock release
3. Hardware interrupt fires and handler blocks on mpc_lock
4. free_irq waits for handler completion, resulting in deadlock

How to detect it

Review kernel logs for repeated mcp251x or CAN subsystem entries around device open failures; correlate with system watchdog or hung-task reports indicating mutex contention in the driver.

What your security team should do

• Identify and prioritize kernel upgrades on all hosts exposing MCP251x CAN interfaces
• Monitor vendor or distribution advisories for backported patches
• Restrict local access to CAN device nodes until patches are deployed