CVE-2026-74691 — net: thunderbolt: Tear down DMA paths before stopping the rings

Affected: Linux

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…

Most recent entries from all

CVE-2026-74691 — net: thunderbolt: Tear down DMA paths before stopping the rings