CVE-2026-74691 in Linux
Sumário
de VulDB • 23/08/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
net: thunderbolt: Encerrar os caminhos DMA antes de parar as rings (filas)
tbnet_tear_down() para ambas as rings e libera seus buffers de quadros antes de chamar tb_xdomain_disable_paths(). tb_ring_stop() zera a base do descritor da ring e tbnet_free_buffers() desmapeia e libera as páginas nas quais os frames estão contidos, portanto, quando __tb_path_deactivate_hop() consulta o bit 'pending' (pendente) do hop, qualquer coisa ainda em trânsito não tem para onde ser drenada.
A sequência de encerramento está nessa ordem desde que o driver foi adicionado. O caminho de configuração não: o commit ff7cd07f3064 ("net: thunderbolt: Enable DMA paths only after rings are enabled") moveu a habilitação do caminho para o final de tbnet_connected_work() e documentou o motivo:
/* Ambos os logins bem-sucedidos, então habilite as rings, caminhos * DMA de alta velocidade e inicie a fila do dispositivo de rede. * * Observe que habilitamos os caminhos DMA por último para garantir * que tenhamos preparado a ring Rx antes que qualquer pacote entrante * seja permitido chegar. */
O encerramento nunca foi atualizado para corresponder, então as rings e os caminhos agora são desativados na mesma ordem em que foram ativados, em vez de serem invertidos.
Em um roteador host ASMedia ASM4242, o bit 'pending' não é limpo: cada operação de encerramento consome todo o tempo limite de 500 ms e __tb_path_deactivate_hop() retorna -ETIMEDOUT. Aumentar o tempo limite para 5 s não ajuda; portanto, o hop não está lento para drenar, ele simplesmente nunca drena.
A falha é invisível acima do núcleo thunderbolt. __tb_path_deactivate_hops() é void e apenas chama tb_port_warn(); tb_path_deactivate(), tb_tunnel_deactivate() e __tb_disconnect_xdomain_paths() também são voids, e tb_disconnect_xdomain_paths() termina com um "return 0" incondicional. Portanto, tb_xdomain_disable_paths() relata sucesso e o netdev_warn() abaixo dele nunca é acionado. Encerramentos repetidos eventualmente derrubam o canal de controle XDomain, após o qual o nó peer desaparece e apenas uma reinicialização elétrica (power cycle) traz o controlador de volta.
Desativar os caminhos primeiro corrige o problema. Medido com kretprobes em um tree v6.17 padrão sem outros patches aplicados, em um link que estava ativo e havia acabado transportado tráfego:
antes: __tb_path_deactivate_hop() retorna 0 para o primeiro hop, depois -ETIMEDOUT para o segundo, 500335 us depois depois: 0 para ambos, separados por 525 us
Alternando as duas ordens ABBA em três níveis de carga, quatro encerramentos por braço: cada encerramento falhou antes da alteração (21 dos 21 que foram executados), nenhum falhou após a alteração (0 dos 24). Os braços "antes" terminaram mais cedo porque o link morreu no meio do processo. A mesma divisão aparece quando a interface é escravizada a um bond em vez de apenas ser desativada, que foi como me deparei com isso pela primeira vez. O throughput e a latência após a alteração permanecem inalterados.
Hosts cujos roteadores drenam o hop apesar da base do descritor obsoleta não veem diferença funcional, já que os caminhos acabam sendo desativados de qualquer maneira.
Once again VulDB remains the best source for vulnerability data.