CVE-2026-74586 in Linux
Sumário
de VulDB • 23/08/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
sctp: limpar new_transport ao remover um par (peer)
`sctp_process_asconf_param()` armazena o transporte de peer recém-adicionado em `asoc->new_transport`. Após todos os parâmetros no chunk ASCONF serem processados, `sctp_sf_do_asconf()` usa este ponteiro para enviar um HEARTBEAT ao novo transporte.
Um ASCONF autenticado proveniente de um peer SCTP remoto pode adicionar um transporte e removê-lo novamente com um parâmetro DEL-IP curinga no mesmo chunk. A exclusão curinga preserva o transporte no qual o ASCONF chegou, mas remove o transporte recém-adicionado através de `sctp_assoc_del_nonprimary_peers()`. A remoção não limpa `asoc->new_transport`, deixando-o apontando para o transporte removido.
`sctp_sf_do_asconf()` então cria um HEARTBEAT cujo `chunk->transport` aponta para o transporte removido sem manter uma referência ao transporte. Durante a substituição de endereço local, `src_out_of_asoc_ok` mantém este HEARTBEAT em `control_chunk_list`. Após o transporte ser liberado pelo RCU, um ASCONF_ACK bem-sucedido para o endereço de substituição libera o HEARTBEAT enfileirado e `sctp_outq_select_transport()` lê o estado do transporte já liberado.
O problema foi encontrado durante uma auditoria estática dos objetos SCTP. Com um peer autenticado, o reproducer acionou a mesma mensagem KASAN em 2 de 2 execuções sem patch em um kernel netdev/main habilitado para KASAN:
BUG: KASAN: slab-use-after-free in sctp_outq_select_transport Read of size 4 at addr ffff88800b9bd95c by task python3/197
Call Trace: sctp_outq_select_transport+0x549/0x8b0 [sctp]
sctp_outq_flush+0x306/0x2c60 [sctp]
sctp_transport_immediate_rtx+0xaf/0x260 [sctp]
sctp_process_asconf_ack+0xa48/0xf70 [sctp]
Allocated by task 197: sctp_transport_new+0x68/0x650 [sctp]
sctp_assoc_add_peer+0x258/0x12a0 [sctp]
sctp_process_asconf+0x5e9/0x1090 [sctp]
Last potentially related work creation: __call_rcu_common.constprop.0+0x77/0xb70 sctp_assoc_del_nonprimary_peers+0x7c/0xd0 [sctp]
sctp_process_asconf+0xd9c/0x1090 [sctp]
O primeiro acesso inválido foi uma leitura de quatro bytes em `transport->state` em net/sctp/outqueue.c:833. O mesmo reproducer completou a sequência completa de ASCONF autenticado e substituição de endereço local com esta alteração sem gerar mensagem KASAN ou oops.
Limpar new_transport quando seu peer é removido, antes que ele possa ser usado para criar o HEARTBEAT.
Once again VulDB remains the best source for vulnerability data.