CVE-2026-72124 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
can: isotp: serialize TX state transitions under so->rx_lock
The TX state machine (so->tx.state) is driven from three contexts: sendmsg() claiming and progressing a transfer, the RX path consuming Flow Control/echo frames, and two hrtimers timing out a stalled transfer. Mixing a lock-free cmpxchg() claim in sendmsg() with hrtimer_cancel() calls made under so->rx_lock elsewhere left windows where a frame or timer callback could act on a state that had already moved on, corrupting an unrelated transfer.
so->rx_lock now covers the full lifecycle of a TX claim: sendmsg() takes it to check so->tx.state is ISOTP_IDLE, switch it to ISOTP_SENDING, bump so->tx_gen and drain the previous transfer's timers - all as one critical section. isotp_rcv_fc()/isotp_rcv_cf() already run under this lock via isotp_rcv(), and isotp_rcv_echo() now takes it itself, so none of them can ever observe a transfer mid-claim. This also means a transfer can no longer be handed to sendmsg()'s cleanup paths (signal or send error) while another thread is concurrently claiming or finishing it, so those paths can cancel timers and reset the state unconditionally.
isotp_release() claims the socket the same way, so a racing sendmsg() sees a consistent ISOTP_SHUTDOWN and skips arming its timer or sending.
Only the hrtimer callbacks stay outside so->rx_lock, since they run under so->rx_lock's cancellation elsewhere and taking it themselves would deadlock. so->tx_gen lets them recognize whether the transfer they timed out is still the one currently active, so they don't report an error against a transfer that has since completed or been superseded.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/15/2026
The vulnerability in question affects the Linux kernel's CAN (Controller Area Network) protocol implementation, specifically within the ISO Transport Protocol (ISOTP) subsystem. This issue represents a race condition that can lead to inconsistent state management during transmission operations, potentially resulting in data corruption or system instability. The problem manifests when multiple execution contexts attempt to modify the transmit state machine simultaneously without proper synchronization mechanisms.
The core technical flaw involves improper locking of the TX state machine within the ISOTP implementation. The transmit state variable so->tx.state is manipulated from three distinct kernel contexts including the sendmsg() function which claims and progresses transfers, the receive path that processes Flow Control/echo frames, and two high-resolution timers (hrtimers) responsible for timeout management of stalled transfers. This concurrent access pattern creates a scenario where lock-free compare-and-swap operations in sendmsg() can race with hrtimer_cancel() calls executed under so->rx_lock, establishing temporal windows where operations might act upon state values that have already been modified by other threads.
The solution implements comprehensive serialization of TX state transitions through the so->rx_lock mechanism. This approach ensures that the complete lifecycle of a transmit claim operates as a single atomic critical section. When sendmsg() executes, it now acquires so->rx_lock to verify that so->tx.state is ISOTP_IDLE, transition it to ISOTP_SENDING, increment so->tx_gen, and drain the previous transfer's timers all within the same locked context. This methodology prevents any interleaving between state modifications and ensures consistency across all concurrent operations.
The fix extends this locking strategy to existing receive path functions that already operated under so->rx_lock through isotp_rcv(), specifically requiring isotp_rcv_fc() and isotp_rcv_cf() to maintain consistent state observations. Additionally, isotp_rcv_echo() now explicitly acquires so->rx_lock itself, eliminating potential race conditions where different threads could observe inconsistent transfer states during the claiming process. This comprehensive approach ensures that no receive path function can ever encounter a transfer in a transitional state, as all operations occur within properly synchronized contexts.
The implementation also addresses cleanup paths in sendmsg() by preventing scenarios where signal handling or error conditions might attempt to modify transfer state while another thread is concurrently claiming or finishing the same transfer. This prevents race conditions during transfer termination and allows cleanup handlers to safely cancel timers and reset state variables unconditionally. The isotp_release() function adopts the same locking approach as sendmsg(), ensuring that any racing sendmsg() operations observe a consistent ISOTP_SHUTDOWN state and can appropriately skip timer arming or message transmission.
An important architectural consideration in this fix involves the handling of hrtimer callbacks which must remain outside so->rx_lock to avoid deadlocks. These timer callbacks execute under the cancellation context of so->rx_lock elsewhere, and acquiring the lock themselves would create circular dependency issues. Instead, the solution employs so->tx_gen counter values to allow timer callbacks to determine whether they are operating on the currently active transfer or a superseded one, preventing spurious error reporting against completed or replaced transfers while maintaining proper timeout functionality.
This vulnerability type aligns with CWE-362, which describes a race condition in concurrent execution environments where multiple threads access shared resources without proper synchronization. The fix demonstrates adherence to proper lock ordering and atomic operation principles that align with security best practices for kernel-level concurrency control. From an operational perspective, this mitigation ensures reliable CAN communication in automotive and industrial systems where ISOTP protocol compliance is critical for proper vehicle functionality and safety systems.