CVE-2026-74586

Resumo

No kernel Linux, a seguinte vulnerabilidade foi resolvida: sctp: limpar new_transport ao remover um peer sctp_process_asconf_param() armazena um transporte de peer recém-adicionado em asoc->new_transport. Depois que todos os parâmetros no chunk ASCONF foram processados, sctp_sf_do_asconf() usa esse ponteiro para enviar um HEARTBEAT ao novo transporte. Um ASCONF autenticado 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 por meio 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 de transporte. Durante a substituição do endereço local, src_out_of_asoc_ok mantém esse HEARTBEAT em control_chunk_list. Após o transporte ser liberado por 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 liberado. O problema foi encontrado durante uma auditoria estática de objetos SCTP. Com um peer autenticado, o reprodutor acionou o mesmo relatório KASAN em 2 de 2 execuções sem patch em um kernel netdev/main habilitado para KASAN: BUG: KASAN: slab-use-after-free em sctp_outq_select_transport Leitura de tamanho 4 no endereço ffff88800b9bd95c pela tarefa python3/197 Rastreamento de chamadas: 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] Alocado pela tarefa 197: sctp_transport_new+0x68/0x650 [sctp] sctp_assoc_add_peer+0x258/0x12a0 [sctp] sctp_process_asconf+0x5e9/0x1090 [sctp] Última criação de trabalho potencialmente relacionada: __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 de transport->state em net/sctp/outqueue.c:833. O mesmo reprodutor concluiu a sequência completa de ASCONF autenticado e substituição de endereço local com esta alteração sem um relatório KASAN ou oops. Limpe new_transport quando seu peer for removido, antes que ele possa ser usado para criar o HEARTBEAT.