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
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.111-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 7.2.6-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.111-1~deb12u1 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.1.191 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.6.157 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.12.109 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.18.50 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 7.2.4 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.115-2Fixed in 7.2.12-1Fixed in 7.2.15-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1 - Configuration
Clear login_sent on every failure path in tbnet_connected_work() so the connection is marked down after bringing it up fails.
Linux kernel net: thunderbolt login_sent = cleared
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.