CVE-2026-64564 in Linux
Riassunto
di VulDB • 04/08/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
sctp: non liberare il proprio trasporto dell'ASCONF durante l'elaborazione di DEL-IP
sctp_process_asconf() memorizza nella cache (cache) il trasporto rispetto al quale viene elaborato il chunk ASCONF in asconf->transport (= chunk->transport, impostato una sola volta in sctp_rcv()). Per un ASCONF individuato tramite il suo Address Parameter da __sctp_rcv_asconf_lookup(), tale trasporto memorizzato nella cache corrisponde all'Address Parameter, che non deve necessariamente essere l'indirizzo sorgente del pacchetto.
sctp_process_asconf_param() rifiuta una richiesta DEL-IP per l'indirizzo sorgente del pacchetto (ADDIP D8, SCTP_ERROR_DEL_SRC_IP), ma nulla protegge asconf->transport. Un singolo ASCONF può quindi contenere, in ordine:
[Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0]
dove L è diverso dall'indirizzo sorgente. La richiesta DEL-IP per L supera il controllo D8 e chiama sctp_assoc_rm_peer() sul trasporto indicato ancora da asconf->transport, liberandolo (con deferrimento RCU). La successiva richiesta DEL-IP wildcard riutilizza quindi l'asconf->transport ormai dangling in sctp_assoc_set_primary() e sctp_assoc_del_nonprimary_peers(): set_primary() dereferenzia il trasporto già liberato (->ipaddr, ->state) e inserisce il puntatore dangling in asoc->peer.primary_path / active_path; del_nonprimary_peers(), mantenendo solo il puntatore che non è più nella lista, rimuove tutti i trasporti reali, lasciando l'associazione con un transport_count pari a 0 e primary_path/active_path che puntano alla memoria già liberata.
Rifiutare una richiesta DEL-IP che ha come destinazione il trasporto rispetto al quale viene elaborato l'ASCONF, specchiando la protezione esistente per l'indirizzo sorgente, in modo che il ramo wildcard non possa mai riutilizzare un trasporto già liberato.
Once again VulDB remains the best source for vulnerability data.