CVE-2026-80889 in Linux
Summary
by MITRE • 09/04/2026
In the Linux kernel, the following vulnerability has been resolved:
can: isotp: fix timer drain order, wakeup handling and tx_gen ordering
This patch is a follow-up to commit cf070fe33bfb ("can: isotp: serialize TX state transitions under so->rx_lock") which addresses following sashiko-bot findings:
- isotp_sendmsg(): drain so->txfrtimer first so a stale callback can't re-arm echotimer after the claim
- isotp_release(): wake so->wait after forcing ISOTP_SHUTDOWN so a sleeping sendmsg() claim isn't stranded
- isotp_sendmsg(): have both wait_event_interruptible() calls in isotp_sendmsg() also wake on ISOTP_SHUTDOWN and do not return claim to IDLE to avoid corrupting a concurrent isotp_release() process.
- isotp_sendmsg(): handle potential claim of a new transfer when the wait_event_interruptible() call returns in CAN_ISOTP_WAIT_TX_DONE mode. Don't touch timers and states of the new transfer if a new thread incremented so->tx_gen before getting the lock at err_event_drop.
- isotp_sendmsg(): handle a stuck can_send() and omit timer and state changes if a new transfer was claimed. wait_tx_done() returns the error recorded in so->tx_result[], tagged with the caller's own generation.
- isotp_tx_timeout(): on a claimed timeout, record the ECOMM error for the timed-out transfer's own generation in so->tx_result[]; sk->sk_err
is raised unconditionally, same as every other error path here.
- isotp_tx_gen_done()/isotp_tx_timeout(): always read tx.state (acquire) before tx_gen - the reverse order let a weakly ordered CPU pair a fresh tx.state with a stale tx_gen/tx_result slot.
- isotp_sendmsg(): wait_tx_done: drain sk_err via sock_error() once we have read the result from so->tx_result[], so an already-reported error
doesn't stay latched for a later poll()/SO_ERROR.
Also align the remaining lock-free so->tx.state/rx.state/cfecho accesses and use skb->hash as unique loopback echo frame indicator.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/04/2026
The Linux kernel Controller Area Network Internet Protocol (CAN ISOTP) implementation contained several critical concurrency flaws related to state management, timer handling, and memory ordering during transmission operations. These vulnerabilities primarily affected the serialization of transmit state transitions and the interaction between sending messages and releasing socket resources. The root cause lies in race conditions where multiple threads or execution paths could access shared socket structures without proper synchronization, leading to corrupted states, stranded processes, and incorrect error reporting. Specifically, the original implementation failed to adequately protect against stale timer callbacks re-arming timers after a transfer claim had been made, which could result in undefined behavior when the system attempted to manage concurrent transmission requests or handle timeouts for transfers that were no longer active.
A significant aspect of this vulnerability involves the ordering of operations within isotp_sendmsg and isotp_release functions. In isotp_sendmsg, the code did not properly drain the transmit frame timer before attempting to claim a new transfer context. This oversight allowed stale callback handlers to re-arm timers even after the current thread had claimed ownership of the transmission state, creating a window where multiple threads might believe they control the same transfer. Furthermore, during socket release operations in isotp_release, the wait queue was not properly woken up after forcing an ISOTP_SHUTDOWN state. This omission could leave sleeping sendmsg calls stranded indefinitely, causing resource leaks and denial-of-service conditions for applications waiting on I/O completion events that would never occur due to the unhandled shutdown signal.
The handling of error states and generation counters also presented serious integrity issues within the kernel networking stack. The implementation failed to ensure that wait_event_interruptible calls in isotp_sendmsg correctly woke up upon ISOTP_SHUTDOWN, potentially allowing a claim to return to an IDLE state incorrectly. This corruption could interfere with concurrent release processes, leading to inconsistent socket states. Additionally, when handling potential claims of new transfers while waiting for transmission completion in CAN_ISOTP_WAIT_TX_DONE mode, the code did not adequately check if another thread had incremented the tx_gen counter before acquiring locks. This lack of verification meant that timer and state modifications could be applied to a transfer context that was no longer valid or owned by the current execution path. Similarly, stuck can_send calls were not properly handled; if a new transfer was claimed while waiting for completion, the code continued to touch timers and states associated with the obsolete transfer rather than respecting the newly established generation counter.
Memory ordering violations further exacerbated these concurrency issues on weakly ordered CPU architectures. The functions isotp_tx_gen_done and isotp_tx_timeout accessed tx.state before tx_gen without proper memory barriers or acquire semantics. This reverse order allowed a processor to pair a fresh state value with stale generation counters or result slots, leading to logical inconsistencies where the system believed a transfer was in one state while actually operating on data from an older context. To mitigate these risks and align lock-free accesses for transmit and receive states as well as control frame echo indicators, the fix introduces strict ordering constraints and utilizes skb->hash as a unique identifier for loopback echo frames. This ensures that even under high concurrency or weak memory models, the kernel maintains accurate tracking of transfer generations and prevents cross-contamination between different transmission contexts.
The operational impact of these vulnerabilities includes potential denial-of-service through hung processes, data corruption in CAN bus communications due to misaligned state transitions, and incorrect error propagation which could mask real network failures or report false errors to user-space applications. An attacker with local access capable of triggering rapid concurrent sendmsg calls on ISOTP sockets could exploit the race conditions to cause kernel instability or application hangs. Mitigation strategies involve applying the upstream Linux kernel patches that enforce proper timer draining, correct wait queue wake-up sequences, and strict memory ordering for generation counters. System administrators should ensure their systems are updated with the latest stable kernel versions containing these fixes. From a defensive perspective, monitoring for unusual patterns in CAN bus traffic or application hangs related to socket I/O can help identify exploitation attempts of this class of concurrency bugs before they lead to system compromise.
These issues map closely to CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization, as the core problem is the lack of proper locking and atomicity checks when accessing shared state variables like tx_gen and timer structures. Additionally, the failure to properly handle timeout states and error reporting aligns with CWE-459 Incomplete Cleanup, where resources are not correctly released or reset during abnormal termination paths such as socket release. The ATT&CK technique T1053 Scheduled Task/Job is less relevant here, but the exploitation vector relates more to local privilege escalation potential if kernel memory corruption occurs due to state misalignment, though primarily this manifests as a reliability and availability issue within the networking subsystem rather than direct code execution. Ensuring strict adherence to synchronization primitives and proper ordering of read-modify-write operations on shared data structures is essential for maintaining integrity in high-concurrency network drivers like CAN ISOTP.