0.0
NA
CVE-2026-80889
can: isotp: fix timer drain order, wakeup handling and tx_gen ordering
Description

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.

INFO

Published Date :

Sept. 4, 2026, 6:17 p.m.

Last Modified :

Sept. 4, 2026, 6:17 p.m.

Remotely Exploit :

No

Source :

416baaa9-dc9f-4396-8d5f-8c081fb06d67
Affected Products

The following products are affected by CVE-2026-80889 vulnerability. Even if cvefeed.io is aware of the exact versions of the products that are affected, the information is not represented in the table below.

No affected product recoded yet

Solution
Fix timer drain order, wakeup handling, and tx_gen ordering to prevent race conditions.
  • Apply the kernel patch.
  • Ensure proper synchronization.
  • Review timer and state access.
  • Validate echo frame indicators.
CWE - Common Weakness Enumeration

While CVE identifies specific instances of vulnerabilities, CWE categorizes the common flaws or weaknesses that can lead to vulnerabilities. CVE-2026-80889 is associated with the following CWEs:

Common Attack Pattern Enumeration and Classification (CAPEC)

Common Attack Pattern Enumeration and Classification (CAPEC) stores attack patterns, which are descriptions of the common attributes and approaches employed by adversaries to exploit the CVE-2026-80889 weaknesses.

We scan GitHub repositories to detect new proof-of-concept exploits. Following list is a collection of public exploits and proof-of-concepts, which have been published on GitHub (sorted by the most recently updated).

Results are limited to the first 15 repositories due to potential performance issues.

The following list is the news that have been mention CVE-2026-80889 vulnerability anywhere in the article.

The following table lists the changes that have been made to the CVE-2026-80889 vulnerability over time.

Vulnerability history details can be useful for understanding the evolution of a vulnerability, and for identifying the most recent changes that may impact the vulnerability's severity, exploitability, or other characteristics.

  • New CVE Received by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

    Sep. 04, 2026

    Action Type Old Value New Value
    Added Description 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.
    Added Affected New affected value received. <a href="https://github.com/CVEProject/cvelistV5/blob/main/cves/2026/80xxx/CVE-2026-80889.json">CVE-2026-80889</a>
    Added Reference https://git.kernel.org/stable/c/050f010f920da17c1044a4f174766ad553e770b6
    Added Reference https://git.kernel.org/stable/c/10be509fa8fd95d1e47d40d1f68b0b26dfe9d572
    Added Reference https://git.kernel.org/stable/c/2753722612d8824d3910096f93059f669009b0f0
    Added Reference https://git.kernel.org/stable/c/35c62ac98d06669aa3f0f38b7829eaca929a611e
    Added Reference https://git.kernel.org/stable/c/8acab9fc66d6f426c36968c91a979f70784945a7
    Added Reference https://git.kernel.org/stable/c/af7e25c649ed68cbad07f8185af0f31b892cbf29
    Added Reference https://git.kernel.org/stable/c/bf5c4a8b24acb12739ebb9aea5510b007e4f5239
    Added Reference https://git.kernel.org/stable/c/deca7746b57d982cd4f0301f4443f56780c4a048
EPSS is a daily estimate of the probability of exploitation activity being observed over the next 30 days. Following chart shows the EPSS score history of the vulnerability.