CVE-2026-80989

What it actually does

A Linux kernel Thunderbolt networking (tbnet) state-tracking bug leaves login_sent set after failed connection bring-up in tbnet_connected_work(). Subsequent tbnet_tear_down() then repeats teardown on already-unwound state: it stops DMA rings that are already stopped (dev_WARN, fatal if panic_on_warn) and releases net->remote_transmit_path even on HopID-mismatch paths this connection never owned, silently freeing a transmit path another connection still uses. That is a use-after-free / invalid free of kernel networking path state and can corrupt kernel memory, panic the host, or enable further kernel-memory integrity loss. Adjacent Thunderbolt access is required (AV:A); no privileges or user interaction are needed once a peer is on the Thunderbolt fabric.

Why it matters to the business

Workstations, docks, and servers using Linux Thunderbolt networking can kernel-panic, lose Thunderbolt Ethernet, or in the worst case suffer kernel compromise from a device on the local Thunderbolt link—not from the open internet. Impact is high (confidentiality, integrity, and availability all rated high) but scope is limited to systems with Thunderbolt networking and an adjacent peer. The issue is about 20 days old, is not listed in CISA KEV, is not associated with ransomware campaigns, and has no public exploit maturity, so urgency is patch-driven rather than active-mass-exploitation-driven. Unpatched laptops that regularly attach Thunderbolt docks, displays, or peer machines remain the primary operational risk.

How an attack unfolds

An attacker who can attach or already control a Thunderbolt peer (cable, malicious dock/adapter, or compromised adjacent host on the Thunderbolt network) participates in Thunderbolt IP login so the victim runs tbnet_connected_work(). They induce a bring-up failure (for example HopID mismatch or a later setup error). Failure paths undo local work but leave login_sent set, so the stack still looks logged in. When teardown runs, the kernel takes the established-connection branch: it warns while stopping already-stopped rings and frees a remote_transmit_path it may not own. That invalid free/use-after-free of kernel path state can crash the box or corrupt kernel objects. Because login_received stays set, a later peer login retries on stale state rather than a clean login, widening the window. No public weaponization or named threat-actor use is indicated.

How to fix it

Apply a Linux kernel update that includes the Thunderbolt networking fix which clears login_sent on tbnet_connected_work() failure paths so tbnet_tear_down() does not re-tear an already unwound connection. Rebuild or install the distribution kernel package that carries this net/thunderbolt change; there are no product-specific version pins in the advisory data, so follow distro/stable-tree kernels that merged the 'Mark the connection down when bringing it up fails' fix. If Thunderbolt networking is not required, disable it (blacklist the Thunderbolt net driver, disable Thunderbolt networking in firmware/OS policy, or withhold Thunderbolt network use) until patched. Avoid panic_on_warn in production as a hard crash amplifier, but do not treat that as a fix. Restrict which Thunderbolt devices may connect (authorized-device / secure-connect policies) to reduce adjacent-attacker exposure.

How to confirm the fix worked

Confirm the running kernel includes the tbnet login_sent-clearing change (distro changelog, stable commit for net/thunderbolt, or inspection that failure paths in tbnet_connected_work() clear login_sent). Inventory hosts with Thunderbolt controllers and the Thunderbolt net driver loaded (module or built-in). After patching, regress by exercising Thunderbolt network connect/fail/disconnect cycles and verify no repeated teardown, no ring-stop warnings, and no unexpected remote_transmit_path release. Unpatched exposure is any Linux system that can load Thunderbolt networking and accept a Thunderbolt peer.

Typical attack path

1. Obtain adjacent access on the Thunderbolt fabric (physical Thunderbolt/USB4 attachment, malicious accessory, or already-compromised Thunderbolt peer).
2. Trigger Thunderbolt networking login so the victim kernel runs connection bring-up (tbnet_connected_work).
3. Cause bring-up to fail after partial setup so login_sent remains set and the connection still appears established.
4. Force or wait for tbnet_tear_down, which double-stops rings and may free a remote_transmit_path/HopID owned by another connection.
5. Abuse the resulting kernel warning/panic or use-after-free of transmit-path state to deny service or corrupt kernel memory.
6. Optionally send a subsequent login so the victim retries connected_work on stale state instead of a fresh login.

How to detect it

This is a kernel-state bug, not a userland implant, so look for crash and WARN artifacts rather than malware files. Search kernel logs (dmesg, journalctl -k, persistent oops/warn collectors, kdump/vmcore) around Thunderbolt network attach/detach for warnings or panics in tbnet_tear_down or tbnet_connected_work, ring-stop warnings on already-stopped rings, and unexpected Thunderbolt net teardown after a failed bring-up. Correlate with physical or peer Thunderbolt login events and HopID mismatch or connection-setup failures. panic_on_warn hosts may show a full panic instead of a WARN. No named APT or ransomware telemetry is associated; absence of these logs does not prove non-exploitation if the box rebooted without persistent kernel logs. Capture vmcore if a Thunderbolt-net WARN/panic recurs after a failed login.

• tbnet_tear_down
• tbnet_connected_work
• net/thunderbolt
• thunderbolt.*WARN
• login_sent
• remote_transmit_path
• HopID
• tbnet_
• thunderbolt networking
• panic_on_warn

What your security team should do

• Prioritize kernel updates on Linux endpoints and servers with Thunderbolt/USB4 that may use Thunderbolt networking, even though this CVE is not in KEV and has no known in-the-wild exploit.
• Treat adjacent physical/Thunderbolt access as in-scope: enforce Thunderbolt device authorization, disable Thunderbolt networking where unused, and control docks/cables.
• Hunt recent dmesg/journal oops and WARN stacks for tbnet_tear_down / tbnet_connected_work; investigate hosts that panicked under panic_on_warn after Thunderbolt net events.
• Do not wait for a named campaign: CVSS 8.8 adjacent UAF in kernel networking is patch-now for Thunderbolt-using fleets; deprioritize internet-only hosts with no Thunderbolt hardware.
• Track distro kernel advisories for the net/thunderbolt login_sent fix and verify package versions after rollout.