CVE-2026-74691 in Linux
Summary
by MITRE • 08/22/2026
In the Linux kernel, the following vulnerability has been resolved:
net: thunderbolt: Tear down DMA paths before stopping the rings
tbnet_tear_down() stops both rings and frees their frame buffers before calling tb_xdomain_disable_paths(). tb_ring_stop() zeroes the ring's descriptor base and tbnet_free_buffers() unmaps and frees the pages the frames sit in, so by the time __tb_path_deactivate_hop() polls the hop's 'pending' bit, anything still in flight has nowhere to drain to.
The teardown sequence has been in this order since the driver was added. The setup path has not: commit ff7cd07f3064 ("net: thunderbolt: Enable DMA paths only after rings are enabled") moved the path enable to the end of tbnet_connected_work() and documented why:
/* Both logins successful so enable the rings, high-speed DMA * paths and start the network device queue. * * Note we enable the DMA paths last to make sure we have primed * the Rx ring before any incoming packets are allowed to * arrive. */
Teardown was never updated to match, so the rings and the paths now come down in the same order they go up instead of in reverse.
On an ASMedia ASM4242 host router the 'pending' bit then never clears: every teardown burns the full 500 ms timeout and __tb_path_deactivate_hop() returns -ETIMEDOUT. Raising the timeout to 5 s does not help, so the hop is not slow to drain, it never drains at all.
The failure is invisible above the thunderbolt core. __tb_path_deactivate_hops() is void and only calls tb_port_warn(); tb_path_deactivate(), tb_tunnel_deactivate() and __tb_disconnect_xdomain_paths() are void as well, and tb_disconnect_xdomain_paths() ends in an unconditional "return 0". So tb_xdomain_disable_paths() reports success and the netdev_warn() below it never fires. Repeated teardowns eventually take the XDomain control channel down, after which the peer node is gone and only a power cycle brings the controller back.
Deactivating the paths first fixes it. Measured with kretprobes on a stock v6.17 tree with no other patches applied, on a link that was up and had just carried traffic:
before: __tb_path_deactivate_hop() returns 0 for the first hop, then -ETIMEDOUT for the second 500335 us later after: 0 for both, 525 us apart
Alternating the two orderings ABBA over three load levels, four teardowns per arm: every teardown failed before the change (21 of 21 that ran), none failed after (0 of 24). The before arms ran short because the link died partway through. The same split shows up when the interface is enslaved to a bond instead of just brought down, which is how I ran into this in the first place. Throughput and latency after the change are unchanged.
Hosts whose routers drain the hop despite the stale descriptor base see no functional difference, since the paths end up deactivated either way.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/22/2026
The Thunderbolt networking driver within the Linux kernel contained a critical race condition in its teardown sequence that resulted in hardware state corruption and permanent link failure on specific host controllers. This vulnerability stems from an incorrect ordering of operations during the disconnection process, where DMA paths were disabled before the associated ring buffers were properly drained and freed. The root cause lies in a historical inconsistency between the initialization and deinitialization logic within the driver code. While the setup path was correctly updated to enable high-speed DMA paths only after rings were primed with frame buffers, ensuring that incoming packets had valid memory destinations, the teardown sequence remained unchanged since the driver's inception. This asymmetry meant that when a connection was terminated, the system would stop the ring descriptors and free their underlying page frames before signaling the hardware to deactivate the physical data paths.
From a technical perspective, this ordering creates a scenario where in-flight DMA transactions lose their memory targets prematurely. When tb_ring_stop is invoked, it zeroes out the descriptor base address for the rings. Subsequently, tbnet_free_buffers unmaps and releases the pages containing the frame buffers. By the time the kernel calls __tb_path_deactivate_hop to poll the hardware's pending bit, any DMA operations still in progress have nowhere to write their data or receive acknowledgments. On certain host routers, such as those utilizing the ASMedia ASM4242 chipset, this lack of a valid drain destination causes the hardware state machine to hang indefinitely. The controller waits for the pending bit to clear, but because the memory resources required to complete the transaction have already been reclaimed by the kernel, the bit never clears. This results in a hard timeout error, specifically returning -ETIMEDOUT after 500 milliseconds, and increasing this timeout does not resolve the issue as the hardware is fundamentally unable to progress without valid buffers.
The operational impact of this vulnerability extends beyond simple connection drops; it leads to persistent controller instability that requires manual intervention. Although the failure occurs deep within the Thunderbolt core functions which are declared void and do not propagate errors up the stack, the consequences are severe for system stability. The __tb_path_deactivate_hop function logs a warning but does not halt execution, leading tb_xdomain_disable_paths to report success erroneously. However, the hardware remains in an error state where it cannot process further commands. Repeated teardown attempts eventually cause the XDomain control channel to fail completely. Once this occurs, the peer node becomes unreachable and invisible to the system. The only recovery mechanism available is a full power cycle of the Thunderbolt controller, which disrupts all connected devices and requires user interaction or automated reboot scripts to restore functionality. This behavior was particularly noticeable when network interfaces were enslaved to bonding configurations, as these scenarios trigger frequent teardown events that expose the race condition reliably.
This flaw aligns with CWE-362, Concurrent Execution using Shared Resource with Improper Synchronization, specifically regarding resource management during state transitions where dependencies are not respected in reverse order of acquisition. It also relates to CWE-401, Missing Release of Memory Resources, although here the release happens too early rather than being missing entirely, causing a use-after-free-like condition from the hardware's perspective. In terms of MITRE ATT&CK, this could be viewed as an availability impact similar to T1529 System Shutdown or Reboot if exploited in a denial-of-service context, though it is primarily a stability defect due to implementation error rather than malicious intent. The vulnerability highlights the importance of symmetric teardown logic where resources are released in the exact reverse order of their allocation and activation to ensure all hardware states can settle correctly before lower-level dependencies are removed.
The resolution involves reordering the teardown sequence so that tb_xdomain_disable_paths is called before stopping the rings and freeing buffers. This ensures that the hardware has a valid window to drain any remaining data into memory before the descriptors are zeroed out and pages unmapped. Testing on affected hardware demonstrated that this fix eliminates the timeout errors, allowing both hops in the path to deactivate successfully within microseconds rather than timing out after half a second. Performance metrics such as throughput and latency remain unchanged post-fix, confirming that the change only affects stability without introducing new performance bottlenecks. Hosts whose routers are capable of draining the hop despite stale descriptors will not notice functional differences, but for those relying on strict hardware state management like the ASMedia ASM4242, this patch is essential to prevent controller lockups and maintain reliable Thunderbolt networking connectivity.