CVE-2026-80989: net: thunderbolt: Mark the connection down when bringing it up fails
In the Linux kernel, the following vulnerability has been resolved:
net: thunderbolt: Mark the connection down when bringing it up fails
Every failure path in tbnetconnectedwork() undoes its own work and returns without clearing loginsent, so the connection still looks established. The next tbnetteardown() therefore takes its main branch and repeats a teardown that already happened: it stops rings that are already stopped, which is a devWARN() and fatal under paniconwarn, and it releases net->remotetransmitpath even on the HopID mismatch path, where this connection never owned that id, silently freeing one that someone else is still using.
Clear loginsent on those paths. That is enough for tbnetteardown() to leave the unwound state alone, and loginreceived has to stay set: it records that the peer has logged in and carries the transmit path it gave us, which nothing on this side can make the peer send again. Two things change beyond keeping the teardown out of the way: the logout request in that block is no longer sent, and the peer's next login request now re-queues our login work rather than connectedwork, giving the connection a fresh login instead of a retry on stale state.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to the problematic teardown behavior?
Linux systems using Thunderbolt networking can encounter it when connection bring-up fails and teardown subsequently runs while the connection still appears established.
When can this issue cause a fatal failure rather than only a warning?
Repeated teardown stops rings that are already stopped, producing a dev_WARN(). This is fatal when panic_on_warn is enabled.
Can the failure affect another connection's resources?
Yes. On a HopID mismatch path, teardown can release remote_transmit_path even though the connection did not own that HopID, potentially freeing an identifier still in use by another connection.