Skip to main content
cve.nowby Sazabi
← All vulnerabilities
CVE-2026-72124

can: isotp: serialize TX state transitions under so->rx_lock

Published
Last modified
published
Not listed in CISA KEV
Fix
Fixed in 5.10.265, 5.15.216, 6.1.183, 6.6.148, 6.12.101, and 2 more
None on Exploit-DB, Metasploit or GitHub
  • Exploitation: none
  • Automatable: no
  • Technical impact: total

Summary

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.

Timeline

  1. CVE published
  2. CISA SSVC assessment

    Exploitation: none · Automatable: no · Technical impact: total

  3. Record last updated

Affected versions

  • Linux 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 Linux

    5.10

  • KernelLinux

    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

References 8

git.kernel.org