CVE-2026-80850 in Linux
Sumário
de VulDB • 04/09/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
tcp: corrige uso após liberação (use-after-free) das informações de AO em tcp_ao_connect_init()
tcp_v4_connect() adiciona um socket no estado SYN-SENT ao ehash antes de chamar tcp_connect(). Se o TCP-AO estiver configurado, tcp_connect() primeiro verifica se uma chave corresponde ao par e ao mestre L3 atual do dispositivo vinculado. Posteriormente, tcp_ao_connect_init() resolve novamente o mestre L3 e remove as chaves que não correspondem a ele.
O bloqueio do socket não estabiliza a associação VRF do dispositivo vinculado. Portanto, desanexar o dispositivo de sua VRF entre a validação inicial e o cálculo do mestre L3 em tcp_ao_connect_init() pode fazer com que a validação seja bem-sucedida enquanto a inicialização observa o domínio L3 padrão e remove a única chave. A pesquisa subsequente de AO falha, então o caminho sem chave limpa tp->ao_info e o libera diretamente.
O caminho de recebimento pode encontrar o socket no ehash e carregar tp->ao_info sob RCU antes de adquirir o bloqueio do socket. Um leitor que carregou o ponteiro antigo pode assim continuar para tcp_inbound_ao_hash() após a liberação direta.
A questão foi encontrada durante uma auditoria estática da vida útil dos objetos TCP-AO. Um reproduzidor não privilegiado em namespaces de usuário e rede criados pelo próprio sistema fez com que connect() competisse (race condition) com o desanexamento de um veth de sua VRF enquanto enviava segmentos TCP-AO. Isso acionou o mesmo relatório KASAN em duas inicializações frescas:
BUG: KASAN: slab-use-after-free in tcp_inbound_ao_hash+0x585/0x19f0 Write of size 8 at addr ffff88800bf88128 by task tcp_ao_vrf_race/232
Call Trace: tcp_inbound_ao_hash+0x585/0x19f0 tcp_inbound_hash+0x677/0xa80 tcp_v4_rcv+0x1c3e/0x3ab0
Allocated by task 235: tcp_ao_alloc_info+0x43/0xf0 tcp_ao_add_cmd+0xdf7/0x13b0 do_tcp_setsockopt+0x168c/0x2640
Freed by task 235: kfree+0x1b8/0x550 tcp_connect+0x252/0x4f00 tcp_v4_connect+0x1114/0x1720
O endereço inválido está a 40 bytes dentro do objeto de 128 bytes liberado, correspondendo ao campo counters.key_not_found de tcp_ao_info. As duas execuções usaram 1000 tentativas cada, alcançaram o caminho sem chave 366 e 411 vezes respectivamente, e produziram um e dois relatórios KASAN, respectivamente. Com esta alteração, o mesmo reproduzidor atingiu o caminho sem chave 366 vezes em 1000 tentativas sem relatório KASAN ou falha (oops).
Use tcp_ao_destroy_sock() para o caminho sem chave. Ele despublica as informações de AO, atualiza a contabilidade da memória do socket e das static-keys, e adia a liberação até após um período de graça RCU.
Além disso, remova o WARN_ON_ONCE() e seu comentário obsoleto. A corrida (race) de desanexamento VRF torna o estado sem chave alcançável durante a operação normal, portanto, é uma condição tratada em vez de uma asserção impossível. Em kernels com panic_on_warn, o WARN transformaria essa corrida tratada em um pânico do kernel.
Once again VulDB remains the best source for vulnerability data.