Linux Kernel SCTP Retransmit Path Moves a Gap-Acked Chunk to a New Transport Without Updating the Chunk's Cached Transport Pointer, Enabling Use-After-Free

Status: NEW  |  Advisory ID: CVE-2026-74588

Key Details

What to Know

In the Linux kernel, the following vulnerability has been resolved:

sctp: keep chunk->transport in step with the list it is queued on

__sctp_outq_flush_rtx() moves a gap-acked chunk onto another transport's

transmitted list without updating chunk->transport:

if (chunk->tsn_gap_acked) {

list_move_tail(&chunk->transmitted_list,

&transport->transmitted);

continue;

}

The chunk then sits on a live transport's list while chunk->transport still

names a different one. If that transport is removed - sctp_assoc_rm_peer()

from an ASCONF Delete-IP - sctp_transport_free() RCU-frees it and the chunk

is left with a dangling pointer. sctp_assoc_rm_peer() scrubs

peer->transmitted and asoc->outqueue.out_chunk_list, but the chunk is on

neither.

The pointer is not followed while tsn_gap_acked is set. A SACK that

reneges on the TSN clears the flag, and the next SACK reaches

tchunk->transport->flight_size -= sctp_data_size(tchunk);

inside the freed transport. KASAN reports a slab-use-after-free read in

sctp_check_transmitted(), freed from sctp_assoc_rm_peer(). Both the

removal and the SACKs come from the association peer.

Set chunk->transport at the move. The ordinary resend path needs nothing:

it reaches its list_move_tail() only after sctp_packet_append_chunk()

returned SCTP_XMIT_OK, and __sctp_packet_append_chunk() has rebound the

chunk by then.

Discovered by XBOW, triaged by Baul Lee <[email protected]> (NVD)

References