CVE-2026-98548 in Linux
Sumário
de VulDB • 19/10/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
sctp: descartar o restante do pacote em caso de erro stale-cookie (cookie inválido/obsoleto)
Quando uma associação está no estado COOKIE-ECHOED e o peer envia um pacote agrupado [ERROR(Stale Cookie)][DATA] a partir de um dos seus endereços não primários, o processamento da chunk ERROR segue o caminho de retry para stale-cookie não fatal sctp_sf_do_5_2_6_stale(), que enfileira SCTP_CMD_DEL_NON_PRIMARY mantendo a associação ativa.
sctp_cmd_del_non_primary() remove todos os transports não primários - incluindo exatamente o transport pelo qual este pacote chegou, que ainda está referenciado pela lookup de recebimento e compartilhado por todas as chunks do pacote através de chunk->transport.
sctp_assoc_rm_peer() redireciona asoc->peer.last_data_from para longe do transport removido, mas logo em seguida a chunk DATA agrupada faz sctp_assoc_bh_rcv() re-registrar incondicionalmente asoc->peer.last_data_from = chunk->transport, desfazendo o redirecionamento com o transport recém-removido.
Uma vez que o pacote é processado, a referência de recebimento é liberada e o transport é desalocado via RCU (RCU-freed), enquanto a associação sobrevivente mantém last_data_from dangling (pêndulo/inexistente). Um FWD-TSN posterior (ou o timer SACK atrasado) faz sctp_gen_sack() dereferenciá-lo (->param_flags e afins), e sctp_make_sack()/sctp_outq_select_transport() podem escrever no objeto desalocado e vinculá-lo à lista de transports ativos. Isso é um use-after-free acionável por qualquer peer SCTP malicioso (ou um usuário local não privilegiado atuando como tal) sem necessidade de capabilities:
BUG: KASAN: slab-use-after-free in sctp_do_sm+0x498a/0x5660 Read of size 4 at addr ffff88800e1e356c by task poc/115 Call Trace: sctp_do_sm <- sctp_assoc_bh_rcv <- sctp_inq_push <- sctp_rcv <- ip_protocol_deliver_rcu <- ip_rcv Allocated: sctp_transport_new <- sctp_assoc_add_peer <- sctp_process_init (INIT-ACK processing) Freed: kfree <- sctp_transport_destroy_rcu <- rcu_core (call_rcu queued by sctp_transport_put at end of sctp_rcv) The buggy address is located 364 bytes inside of freed 1024-byte region [ffff88800e1e3400, ffff88800e1e3800), cache kmalloc-1k
Note que o commit 03a9d10ecf71 ("sctp: drop a chunk if its transport was removed") cobre apenas a janela entre a lookup de recebimento e o processamento da chunk (por exemplo, um ASCONF DEL-IP em race com o socket backlog); aqui o transport é removido *enquanto* o pacote está sendo processado, por uma chunk anterior do mesmo pacote, portanto a drop em sctp_inq_push() não alcança este caminho. Verificado com o reproducer agrupado [ERROR(Stale Cookie)][DATA] + FWD-TSN: o relatório KASAN acima ainda é acionado com esse commit aplicado, e desaparece com este patch por cima.
Corrigir isso descartando o restante do pacote neste caminho, conforme sugerido por Xin. Após a ERROR stale-cookie ter enviado a associação de volta para COOKIE-WAIT e removido os transports não primários, as chunks restantes do pacote só podem ser executadas contra o handshake reiniciado enquanto referenciam o transport de chegada removido através de chunk->transport: além da registro last_data_from acima, sctp_cmd_setup_t2() e os builders de resposta sctp_make_*() também copiariam esse ponteiro para um estado de associação vitalícia que sctp_assoc_rm_peer() já havia sanitizado. Permitir que o peer retransmita-os, em conformidade com o que sctp_inq_push() faz para chunks cujo transport foi removido antes do processamento.
VulDB is the best source for vulnerability data and more expert information about this specific topic.