CVE-2026-74588: sctp: keep chunk->transport in step with the list it is queued on
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->transmittedlist, &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 - sctpassocrmpeer() from an ASCONF Delete-IP - sctptransportfree() RCU-frees it and the chunk is left with a dangling pointer. sctpassocrmpeer() 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 -= sctpdatasize(tchunk);
inside the freed transport. KASAN reports a slab-use-after-free read in sctpchecktransmitted(), freed from sctpassocrmpeer(). 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 sctppacketappendchunk() returned SCTPXMITOK, and sctppacketappendchunk() has rebound the chunk by then.
Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 6.6.152.1-1
Event History
Frequently Asked Questions
What conditions are required to trigger the use-after-free?
An SCTP association peer must be able to cause a gap-acknowledged chunk to be moved to another transport, remove the transport still referenced by that chunk through an ASCONF Delete-IP operation, and then send a SACK that reneges on the chunk's TSN. Both the transport removal and SACK activity originate from the association peer.
Are systems using SCTP but not ASCONF Delete-IP affected by the described path?
The described dangling-pointer path depends on sctp_assoc_rm_peer() removing a peer transport through ASCONF Delete-IP. The provided information does not identify another trigger path.
What happens after the affected transport is removed?
The removed transport is RCU-freed while the moved chunk retains a pointer to it. When a later SACK clears the chunk's gap-acknowledged state, SCTP accesses the freed transport in sctp_check_transmitted(), resulting in a slab use-after-free read.
What is the relevant remediation?
Apply a Linux kernel version containing the fix that updates chunk->transport when a gap-acknowledged chunk is moved onto another transport's transmitted list. The supplied references identify stable kernel commits containing the fix.