CVE-2026-74691

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: thunderbolt: Tear down DMA paths before stopping the rings<br /> <br /> tbnet_tear_down() stops both rings and frees their frame buffers before<br /> calling tb_xdomain_disable_paths(). tb_ring_stop() zeroes the ring&amp;#39;s<br /> descriptor base and tbnet_free_buffers() unmaps and frees the pages the<br /> frames sit in, so by the time __tb_path_deactivate_hop() polls the hop&amp;#39;s<br /> &amp;#39;pending&amp;#39; bit, anything still in flight has nowhere to drain to.<br /> <br /> The teardown sequence has been in this order since the driver was added.<br /> The setup path has not: commit ff7cd07f3064 ("net: thunderbolt: Enable<br /> DMA paths only after rings are enabled") moved the path enable to the end<br /> of tbnet_connected_work() and documented why:<br /> <br /> /* Both logins successful so enable the rings, high-speed DMA<br /> * paths and start the network device queue.<br /> *<br /> * Note we enable the DMA paths last to make sure we have primed<br /> * the Rx ring before any incoming packets are allowed to<br /> * arrive.<br /> */<br /> <br /> Teardown was never updated to match, so the rings and the paths now come<br /> down in the same order they go up instead of in reverse.<br /> <br /> On an ASMedia ASM4242 host router the &amp;#39;pending&amp;#39; bit then never clears:<br /> every teardown burns the full 500 ms timeout and<br /> __tb_path_deactivate_hop() returns -ETIMEDOUT. Raising the timeout to<br /> 5 s does not help, so the hop is not slow to drain, it never drains<br /> at all.<br /> <br /> The failure is invisible above the thunderbolt core.<br /> __tb_path_deactivate_hops() is void and only calls tb_port_warn();<br /> tb_path_deactivate(), tb_tunnel_deactivate() and<br /> __tb_disconnect_xdomain_paths() are void as well, and<br /> tb_disconnect_xdomain_paths() ends in an unconditional "return 0". So<br /> tb_xdomain_disable_paths() reports success and the netdev_warn() below<br /> it never fires. Repeated teardowns eventually take the XDomain control<br /> channel down, after which the peer node is gone and only a power cycle<br /> brings the controller back.<br /> <br /> Deactivating the paths first fixes it. Measured with kretprobes on a<br /> stock v6.17 tree with no other patches applied, on a link that was up<br /> and had just carried traffic:<br /> <br /> before: __tb_path_deactivate_hop() returns 0 for the first hop, then<br /> -ETIMEDOUT for the second 500335 us later<br /> after: 0 for both, 525 us apart<br /> <br /> Alternating the two orderings ABBA over three load levels, four<br /> teardowns per arm: every teardown failed before the change (21 of 21<br /> that ran), none failed after (0 of 24). The before arms ran short<br /> because the link died partway through. The same split shows up when<br /> the interface is enslaved to a bond instead of just brought down, which<br /> is how I ran into this in the first place. Throughput and latency after<br /> the change are unchanged.<br /> <br /> Hosts whose routers drain the hop despite the stale descriptor base see<br /> no functional difference, since the paths end up deactivated either way.