Re: [PATCH net v2] sctp: keep chunk->transport in step with the list it is queued on

On Wed, Jul 29, 2026 at 8:49=E2=80=AFAM Baul Lee <[email protected]> wrote:
>
> __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 +=3D chunk_len;
>         chunk->transport =3D 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 -=3D 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 <[email protected]>
> [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: [email protected]
> Signed-off-by: Baul Lee <[email protected]>
> ---
> 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.le=
[email protected]/
>
>  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 =3D 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 =3D transport;
>
This one seems redundant on the default/SCTP_XMIT_OK path, as it's
already set by:

  chunk->transport =3D 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 retransm=
it
>                          * after it is retransmitted.
> --
> 2.53.0
>