CVE-2026-74588 in Linux
Zusammenfassung
von VulDB • 22.08.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
sctp: chunk->transport mit der Liste synchronisieren, auf der es eingereiht ist
__sctp_outq_flush_rtx() verschiebt ein über Gap-Ack bestätigtes Chunk (chunk) in die Übertragungsliste eines anderen Transports, ohne chunk->transport zu aktualisieren:
if (chunk->tsn_gap_acked) {
list_move_tail(&chunk->transmitted_list, &transport->transmitted); continue; }
Das Chunk verbleibt daraufhin auf der Liste eines aktiven Transports, während chunk->transport weiterhin einen anderen Transport angibt. Wenn dieser Transport entfernt wird – sctp_assoc_rm_peer() im Rahmen einer ASCONF Delete-IP-Anweisung –, wird er über RCU (Read-Copy-Update) freigegeben (sctp_transport_free()), und das Chunk verbleibt mit einem hängenden Zeiger (dangling pointer). sctp_assoc_rm_peer() bereinigt zwar peer->transmitted und asoc->outqueue.out_chunk_list, doch befindet sich das Chunk in keiner dieser Listen.
Der Zeiger wird nicht dereferenziert, solange tsn_gap_acked gesetzt ist. Ein SACK-Paket, das die Bestätigung des TSN widerruft (reneges), löscht dieses Flag, und der nächste SACK führt zu:
tchunk->transport->flight_size -= sctp_data_size(tchunk);
innerhalb des bereits freigegebenen Transports. KASAN meldet einen slab-use-after-free-Lesezugriff in sctp_check_transmitted(), das von sctp_assoc_rm_peer() freigegeben wurde. Sowohl die Entfernung als auch die SACKs stammen vom Peer der Assoziation.
Setzen Sie chunk->transport bei der Verschiebung neu. Der normale Neusendepfad erfordert keine Änderungen: Er erreicht list_move_tail() erst, nachdem sctp_packet_append_chunk() SCTP_XMIT_OK zurückgegeben hat, und __sctp_packet_append_chunk() hat das Chunk bis dahin bereits erneut gebunden (rebound).
Entdeckt von XBOW, triagiert von Baul Lee <[email protected]>
If you want to get best quality of vulnerability data, you may have to visit VulDB.