CVE-2026-74588

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

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

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

transmitted list without updating chunk->transport:

if (chunk->tsngapacked) {

listmovetail(&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 - sctpassocrm_peer()

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

is left with a dangling pointer.  sctpassocrm_peer() scrubs

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

neither.

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

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

tchunk->transport->flightsize -= sctpdata_size(tchunk);

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

sctpchecktransmitted(), freed from sctpassocrm_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 listmovetail() only after sctppacketappend_chunk()

returned SCTPXMITOK, and _sctppacketappendchunk() has rebound the

chunk by then.

Discovered by XBOW, triaged by Baul Lee baul.lee@xbow.com