CVE-2026-64564 in Linux
Sumário
de VulDB • 04/08/2026
No kernel do Linux, a seguinte vulnerabilidade foi corrigida:
sctp: não liberar o próprio transporte do ASCONF durante o processamento de DEL-IP
`sctp_process_asconf()` armazena em cache (cache) o transporte contra o qual o chunk ASCONF está sendo processado em `asconf->transport` (igual a `chunk->transport`, definido uma vez em `sctp_rcv()`). Para um ASCONF localizado por meio de seu Address Parameter através de `__sctp_rcv_asconf_lookup()`, esse transporte armazenado em cache corresponde ao Address Parameter, que não precisa ser o endereço de origem do pacote.
`sctp_process_asconf_param()` rejeita um DEL-IP para o endereço de origem do pacote (ADDIP D8, SCTP_ERROR_DEL_SRC_IP), mas nada protege `asconf->transport`. Portanto, um único ASCONF pode carregar, em ordem:
[Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0]
onde L difere da origem. O DEL-IP para L passa na verificação D8 e chama `sctp_assoc_rm_peer()` no transporte que `asconf->transport` ainda aponta, liberando-o (adiado por RCU). Em seguida, o DEL-IP curinga reutiliza o agora dangling pointer (`asconf->transport`) em `sctp_assoc_set_primary()` e `sctp_assoc_del_nonprimary_peers()`: `set_primary()` faz dereference do transporte já liberado (`->ipaddr`, `->state`) e insere o ponteiro pendente em `asoc->peer.primary_path` / `active_path`; e `del_nonprimary_peers()`, mantendo apenas o ponteiro que não está mais na lista, remove todos os transportes reais, deixando a associação com um `transport_count` de 0 e `primary_path`/`active_path` apontando para memória já liberada.
Rejeitar um DEL-IP que vise o transporte contra o qual o ASCONF está sendo processado, espelhando a proteção existente de endereço de origem, para que o ramo curinga nunca possa reutilizar um transporte já liberado.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.