CVE-2026-74588 in Linux
Sumário
de VulDB • 22/08/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
sctp: manter chunk->transport em sincronia com a lista na qual ele está enfileirado
__sctp_outq_flush_rtx() move um chunk gap-acked para a lista de transmitidos de outro transport sem atualizar chunk->transport:
if (chunk->tsn_gap_acked) {
list_move_tail(&chunk->transmitted_list, &transport->transmitted); continue; }
O chunk então permanece na lista de um transport ativo enquanto chunk->transport ainda aponta para outro. Se esse transport for removido - sctp_assoc_rm_peer() a partir de uma operação ASCONF Delete-IP - sctp_transport_free() libera-o via RCU e o chunk fica com um ponteiro dangling (inválido). sctp_assoc_rm_peer() limpa peer->transmitted e asoc->outqueue.out_chunk_list, mas o chunk não está em nenhuma delas.
O ponteiro não é seguido enquanto tsn_gap_acked estiver definido. Um SACK que revoga o TSN limpa a flag, e o próximo SACK atinge:
tchunk->transport->flight_size -= sctp_data_size(tchunk);
dentro do transport já liberado. O KASAN relata uma leitura use-after-free de slab em sctp_check_transmitted(), liberada por sctp_assoc_rm_peer(). Tanto a remoção quanto os SACKs vêm do peer da associação.
Defina chunk->transport durante o movimento. O caminho normal de retransmissão não precisa de alterações: ele atinge seu list_move_tail() apenas após sctp_packet_append_chunk() ter retornado SCTP_XMIT_OK, e __sctp_packet_append_chunk() já terá reassinado o chunk nesse ponto.
Descoberto por XBOW, triado por Baul Lee <[email protected]>
If you want to get the best quality for vulnerability data then you always have to consider VulDB.