CVE-2026-80990

What it actually does

A resource-management bug in the Linux kernel Thunderbolt networking (tbnet) path leaks Rx HopIDs. During XDomain setup, tbnet_connected_work() requests the peer transmit-path HopID via tb_xdomain_alloc_in_hopid(); ida_alloc_range() may legitimately return a different ID than the requested lower bound if that ID is already taken. The caller treated any mismatch as failure and returned without releasing the allocated ID, so the IDA entry remained reserved for the life of the XDomain connection with no owner. Repeated mismatches can exhaust HopID allocations and prevent further Thunderbolt network path setup (availability impact / DoS), without memory corruption or privilege escalation.

Why it matters to the business

Linux systems that use Thunderbolt networking (peer-to-peer links, some docks or daisy-chain setups) can lose the ability to bring up new Thunderbolt network connections if HopIDs are exhausted, causing local connectivity outages rather than data theft or remote takeover. Blast radius is limited to hosts with Thunderbolt networking in use; typical servers and cloud workloads without Thunderbolt are unaffected. The issue is not in CISA KEV, is not associated with ransomware, and has no reported in-the-wild exploitation (exploit maturity none) about 20 days after publication, so urgency is patch-hygiene driven rather than incident-driven.

How an attack unfolds

An attacker who can participate in Thunderbolt XDomain connection setup against a vulnerable kernel—typically via a physically attached Thunderbolt peer, dock, or similarly adjacent link—induces HopID mismatches while tbnet_connected_work() runs. Each mismatch leaves an allocated Rx HopID unreleased. Over successive connect or reconnect cycles the HopID IDA pool is depleted, after which legitimate Thunderbolt networking fails to allocate paths and new links cannot be established. This is a local/adjacent availability attack on the Thunderbolt net control path, not an unauthenticated remote network exploit, and no named threat actors or public exploit activity are associated with it.

How to fix it

Apply the Linux kernel update from your distribution or vendor that includes the Thunderbolt networking fix described as releasing the Rx HopID handed out on mismatch (net: thunderbolt). No specific upstream or distro package versions were supplied with this record, so track kernel changelogs and stable-tree backports for that change and upgrade to the first available patched kernel for your branch. If Thunderbolt networking is not required, disable it (blacklist or unload the Thunderbolt net driver, and/or disable Thunderbolt networking in firmware/OS policy) and restrict Thunderbolt device authorization (authorized-only/bolt policy, USB4/Thunderbolt security level) so untrusted peers cannot drive XDomain setup. Reboot into the patched kernel to make the fix active.

How to confirm the fix worked

Confirm the running kernel includes the HopID-release fix by checking distro advisory mapping, kernel changelog, or git history for the thunderbolt net mismatch-release change; uname -r and package changelog are sufficient evidence. On a test host, after upgrade, exercise Thunderbolt XDomain/network bring-up and verify connections succeed under repeated connect/disconnect without progressive allocation failure. On production, inventory hosts with Thunderbolt hardware and the thunderbolt/tbnet modules loaded, and treat unpatched kernels in that set as exposed.

Typical attack path

1. Gain Thunderbolt/XDomain adjacency to a Linux host running a vulnerable kernel with Thunderbolt networking enabled.
2. Trigger tbnet connection setup so tbnet_connected_work() allocates an Rx HopID for the peer transmit path.
3. Cause the allocator to return a HopID other than the requested ID (mismatch treated as failure).
4. Leave the connection path so the mismatched ID is not released and remains reserved in the IDA.
5. Repeat connect/mismatch cycles until HopID allocations are exhausted and further Thunderbolt network connections fail.

How to detect it

There is no public exploit, no KEV activity, and no named actor tradecraft, so look for symptoms of HopID exhaustion and Thunderbolt net setup failure rather than a distinctive implant. Review kernel logs (dmesg, journalctl -k, persistent /var/log/kern.log or equivalent) around Thunderbolt attach and networking bring-up for tbnet/thunderbolt XDomain connection failures, HopID allocation errors, and repeated connect/disconnect of Thunderbolt network interfaces. Correlate with physical or dock attach events (udev, bolt, thunderbolt bus add/remove) and with the thunderbolt and thunderbolt-net modules being loaded. Persistent inability to establish Thunderbolt networking after peer attach, especially after many reconnects on an unpatched kernel, is the practical pre-patch indicator; this leak does not leave unique files, registry keys, or C2 beacons.

What your security team should do

• Prioritize kernel updates on Linux endpoints and workstations with Thunderbolt controllers; deprioritize fleets with no Thunderbolt hardware.
• Where patching will lag, disable Thunderbolt networking and enforce authorized-device Thunderbolt/USB4 policy so untrusted peers cannot start XDomain setup.
• Track distro stable kernels for the net/thunderbolt HopID-release backport; this CVE is DoS-family, not KEV, and has no known exploit, so schedule with normal kernel patch SLAs unless Thunderbolt net is business-critical.
• Add the thunderbolt net driver and related kernel logs to vulnerability-exception and patch-validation checklists so exposure and fix status can be reported.
• Reassess only if public exploit code or KEV listing appears; current evidence does not justify emergency change windows.