Re: [PATCH net] sctp: drop a backlogged chunk if its transport was removed

On Mon, Aug 17, 2026 at 04:59:39PM -0400, Xin Long wrote:
> On Mon, Aug 17, 2026 at 1:48 PM Xin Long <[email protected]> wrote:
> >
> > On Fri, Aug 14, 2026 at 7:43 PM Hyunwoo Kim <[email protected]> wrote:
> > >
> > > sctp_rcv() resolves the transport once per packet and leaves it in
> > > chunk->transport. If the socket is owned by userspace the packet goes to
> > > the socket backlog, and sctp_add_backlog() takes a reference on that
> > > transport.
> > >
> > > An authenticated ASCONF DEL-IP in an earlier backlogged packet can remove
> > > it. sctp_assoc_rm_peer() takes the transport out of the association and
> > > calls sctp_transport_free(), which tags it dead and drops the reference
> > > the association held. The backlogged packet still holds a reference, so
> > > the transport stays around.
> > >
> > > The DATA chunk in that packet puts the removed transport back into
> > > asoc->peer.last_data_from. Once the packet is done that reference goes
> > > away and the transport is freed by RCU, so the next delayed SACK carries
> > > the pointer into the SACK chunk and sctp_outq_select_transport() reads the
> > > freed transport's state.
> > >
> > > Drop the chunk in sctp_backlog_rcv(), next to the existing rcvr->dead
> > > check. The peer retransmits it. Guarding the last_data_from assignment is
> > > not enough, sctp_assoc_rm_peer() clears more than that one pointer and
> > > letting the packet run fills them in again. sctp_wait_for_sndbuf() already
> > > uses the dead flag this way on the send side.
> > >
> > > Fixes: df132eff4638 ("sctp: clear the transport of some out_chunk_list chunks in sctp_assoc_rm_peer")
> Please also double check the 'Fixes' tag, commit df132eff4638 doesn't
> seem to cause the issue.

Understood. I'll run a few more tests and then submit v2.


Best regards,
Hyunwoo Kim