Re: [PATCH net v2] sctp: keep chunk->transport in step with the list it is queued on
From: Xin Long <lucien.xin@gmail.com>
Date: 2026-07-29 15:47:34
Also in:
linux-sctp, lkml, stable
On Wed, Jul 29, 2026 at 8:49 AM Baul Lee [off-list ref] wrote:
quoted hunk ↗ jump to hunk
__sctp_outq_flush_rtx() moves a chunk onto transport->transmitted in two places but only one of them leaves chunk->transport describing where the chunk actually is. The ordinary resend path is consistent because sctp_packet_append_chunk() rebinds the chunk in __sctp_packet_append_chunk(): list_add_tail(&chunk->list, &packet->chunk_list); packet->size += chunk_len; chunk->transport = packet->transport; The gap-acked path has no such rebind. It parks the chunk on another transport's transmitted list and leaves the stale back-pointer alone: if (chunk->tsn_gap_acked) { list_move_tail(&chunk->transmitted_list, &transport->transmitted); continue; } So a chunk can sit on a live transport's transmitted list while chunk->transport still names a different transport. If that transport is then removed - sctp_assoc_rm_peer() from an ASCONF Delete-IP - the last reference goes away and sctp_transport_free() RCU-frees it, leaving the chunk with a dangling pointer. sctp_assoc_rm_peer() scrubs the back-pointer on peer->transmitted and on asoc->outqueue.out_chunk_list, but this chunk is on neither. While tsn_gap_acked stays set the dangling pointer is not followed, since sctp_check_transmitted() skips the flight accounting for gap-acked chunks. A later SACK that reneges on the TSN clears the flag, and the next SACK then reaches tchunk->transport->flight_size -= sctp_data_size(tchunk); a read-modify-write inside the freed sctp_transport. KASAN reports a slab-use-after-free read of 4 bytes at offset 216 of a freed kmalloc-1k sctp_transport in sctp_check_transmitted(), freed from sctp_assoc_rm_peer() via sctp_process_asconf(). The removal and the faulting SACKs all come from the association peer, so an application that speaks SCTP and accepts multihoming is enough to reach it. Assign chunk->transport after both list_move_tail() calls, so the back-pointer always matches the list the chunk is queued on. Doing it on the ordinary path too keeps the invariant local to the move instead of resting on a rebind that happens later and only if the chunk is appended to a packet. Fixing it here rather than by scrubbing more lists in sctp_assoc_rm_peer() covers the chunks that were already migrated before the transport went away, which a scrub at removal time cannot see. Discovered by XBOW, triaged by Baul Lee [off-list ref] [Reported privately to the maintainers on 2026-07-10 with root-cause analysis, a PoC, a KASAN log and a fix; posting to the list was requested as the follow-up.] Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Baul Lee <redacted> --- v2: - fix the root cause in __sctp_outq_flush_rtx() instead of clearing the back-pointer for the retransmit queue in sctp_assoc_rm_peer(). The v1 scrub could not see chunks that had already been migrated onto another transport's transmitted list before the removal, which is the case the reviews on v1 asked about - correct the Fixes tag: the inconsistency is as old as the code, not introduced by df132eff4638 Link to v1: https://lore.kernel.org/netdev/20260726060453.42730-1-baul.lee@xbow.com/ (local) net/sctp/outqueue.c | 2 ++ 1 file changed, 2 insertions(+)diff --git a/net/sctp/outqueue.c b/net/sctp/outqueue.c index f6b8c13da..1b2d08f2e 100644 --- a/net/sctp/outqueue.c +++ b/net/sctp/outqueue.c@@ -650,6 +650,7 @@ static int __sctp_outq_flush_rtx(struct sctp_outq *q, struct sctp_packet *pkt, if (chunk->tsn_gap_acked) { list_move_tail(&chunk->transmitted_list, &transport->transmitted); + chunk->transport = transport; continue; }@@ -715,6 +716,7 @@ static int __sctp_outq_flush_rtx(struct sctp_outq *q, struct sctp_packet *pkt, */ list_move_tail(&chunk->transmitted_list, &transport->transmitted); + chunk->transport = transport;
This one seems redundant on the default/SCTP_XMIT_OK path, as it's already set by: chunk->transport = packet->transport; in __sctp_packet_append_chunk(). Could you please remove the second one? (Sorry for not noticing this on v1) Thanks.
/* Mark the chunk as ineligible for fast retransmit
* after it is retransmitted.
--
2.53.0