CVE-2024-41088

What it actually does

Failure in mcp251xfd_start_xmit increments tx_ring->head without decrementing on error, causing mcp251xfd_handle_tefif_one to wait indefinitely for a nonexistent response and the interrupt handler to loop forever when multiple devices share an SPI bus.

Why it matters to the business

Embedded Linux systems using the mcp251xfd CAN controller experience complete loss of CAN bus communication and CPU lockup, disrupting automotive, industrial, or IoT control loops until reboot.

How an attack unfolds

An attacker with local access or control over another SPI device triggers concurrent bus access that returns -EBUSY from mcp251xfd_start_xmit; the driver then skips a TX slot while the TEF handler spins, producing the repeating error messages and preventing any further transmission.

How to fix it

Update the Linux kernel to the commit f926c022ebaabf7963bebf89a97201d66978a025 or later stable releases that contain the fix; the patch starts a workqueue for synchronous TX on -EBUSY and properly cleans up the echo stack on other errors.

How to confirm the fix worked

Verify the running kernel contains commit f926c022ebaabf7963bebf89a97201d66978a025, reproduce concurrent SPI load with a failing xmit, and confirm the driver no longer logs repeated "ERROR in mcp251xfd_start_xmit" messages or enters an uninterruptible loop.

Typical attack path

1. Obtain local execution or control a second SPI peripheral on the same bus
2. Force concurrent SPI transactions while a CAN frame is being transmitted
3. Induce mcp251xfd_start_xmit to return -EBUSY
4. Observe tx_ring->head advance without corresponding TEF entry
5. Trigger infinite loop in interrupt context and resulting DoS

How to detect it

Search kernel logs for repeated occurrences of "ERROR in mcp251xfd_start_xmit: -16" and "Transmit Event FIFO buffer not empty" messages; correlate with high CPU usage in interrupt context on systems using the mcp251xfd driver.

• ERROR in mcp251xfd_start_xmit: -16
• Transmit Event FIFO buffer not empty
• mcp251xfd spi.* can.*: ERROR in mcp251xfd_start_xmit

What your security team should do

• Patch all affected kernels to the fixed commit within the next maintenance window
• Audit embedded devices sharing SPI buses with mcp251xfd controllers
• Add monitoring for the specific mcp251xfd error strings in system logs
• Test CAN functionality under concurrent SPI load after patching