CVE-2024-46702

What it actually does

In the Linux kernel Thunderbolt subsystem, failure to mark XDomain as unplugged on parent router removal allows tb_disconnect_xdomain_paths() to block indefinitely on the domain lock after paths have already been cleaned in tb_stop(), producing a deadlock during hot-remove of a discrete host router following NVM firmware authentication.

Why it matters to the business

Thunderbolt-connected multi-host systems may hang during router NVM upgrades, causing unplanned downtime and requiring physical intervention or forced reboots; low EPSS indicates limited external exploit risk but still affects kernel stability in affected Linux distributions.

How an attack unfolds

An attacker with local access or hardware control initiates a discrete host router NVM upgrade that triggers PCIe-side hot-remove; with enabled paths to another host present, the Thunderbolt networking driver blocks in path teardown, resulting in denial of service. No named threat actors have been observed exploiting this race condition.

How to fix it

Upgrade the Linux kernel to the fixed commit 747bc154577de6e6af4bc99abfa859b8419bb4d8 or later stable releases that include the change marking XDomain unplugged on router removal.

How to confirm the fix worked

Verify the running kernel contains commit 747bc154577de6e6af4bc99abfa859b8419bb4d8; confirm absence of hangs during simulated Thunderbolt router NVM hot-remove scenarios in test environments.

Typical attack path

1. Gain local or hardware access to trigger Thunderbolt NVM upgrade on a discrete host router
2. Force hot-remove of the router from the PCIe side during firmware authentication
3. Ensure enabled Thunderbolt paths exist to a second host
4. Trigger tb_stop() cleanup followed by tb_disconnect_xdomain_paths() to induce deadlock on domain lock

How to detect it

Review kernel logs for repeated calls to tb_disconnect_xdomain_paths() or domain lock contention during Thunderbolt router removal events; correlate with NVM upgrade or hot-remove timestamps.

What your security team should do

• Apply kernel updates containing commit 747bc154577de6e6af4bc99abfa859b8419bb4d8 to all affected systems
• Test Thunderbolt multi-host configurations after patching to validate path teardown behavior
• Monitor kernel logs for Thunderbolt deadlock signatures until patches are deployed