Re: [PATCH net v2] sctp: fix stream->outcnt underflow on duplicate RECONF responses

[Xin Long]

On Wed, Aug 5, 2026 at 8:35 AM Simon Horman <horms@xxxxxxxxxx> wrote:
>
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> Full review at: https://sashiko.dev/#/patchset/20260804113100.37840-1-juny24602@xxxxxxxxx?part=1
> ---
> --- Patch [1]: [PATCH net v2] sctp: fix stream->outcnt underflow on duplicate RECONF responses ---
> commit 9a827b81b27b219603b09c1f04c9dbc9a6dd2368
> Author: Jun Yang <junvyyang@xxxxxxxxxxx>
>
> sctp: fix stream->outcnt underflow on duplicate RECONF responses
>
> This commit addresses a bug where duplicate RECONF responses could cause
> stream->outcnt to underflow. It converts strreset_outstanding into a bitmask
> to track request parameter types, ensuring duplicate responses are ignored.
>
> > diff --git a/net/sctp/stream.c b/net/sctp/stream.c
> > index 34ffe6c945a4b..cb7543929d657 100644
> > --- a/net/sctp/stream.c
> > +++ b/net/sctp/stream.c
>
> [ ... ]
>
> > @@ -928,7 +936,7 @@ struct sctp_chunk *sctp_process_strreset_resp(
> >       __u32 result;
> >
> >       req = sctp_chunk_lookup_strreset_param(asoc, resp->response_seq, 0);
> > -     if (!req)
> > +     if (!req || !SCTP_STRRESET_TEST(asoc, req->type))
> >               return NULL;
>
> [Severity: High]
> Could the new duplicate-drop logic permanently drop legitimate responses when
> the sequence number wraps to 0?
>
> If a user calls setsockopt(SCTP_ADD_STREAMS) with both incoming and outgoing
> streams when asoc->strreset_outseq is exactly 0xFFFFFFFF, it creates a RECONF
> chunk with request_seq = 0xFFFFFFFF for ADD_OUT and request_seq = 0 for
> ADD_IN.
>
> When the peer responds to the ADD_IN request with resp_seq = 0,
> sctp_chunk_lookup_strreset_param() handles it:
>
> net/sctp/stream.c:sctp_chunk_lookup_strreset_param() {
>     ...
>     if ((!resp_seq || req->request_seq == resp_seq) &&
>         (!type || type == req->param_hdr.type))
>             return param.v;
>     ...
> }
>
> Because resp_seq is 0, the !resp_seq check bypasses sequence matching and
> returns the first parameter in the chunk (ADD_OUT).
>
> Since the ADD_OUT bit was already cleared by the first response, the new
> !SCTP_STRRESET_TEST() check here would see the bit is cleared and drop the
> response as a duplicate.
>
> This would leave the ADD_IN bit set forever, preventing the RECONF chunk from
> being freed and causing the association to hang due to endless
> retransmissions.

resp_seq == 0 is a valid value and must not be used to indicate a wildcard
lookup. This is a pre-existing issue, but it would be better to fix it before
this patch.

Hi Jun Yang,

Could you please address this by adding a 'bool match_seq' parameter to
sctp_chunk_lookup_strreset_param()?

After that, please repost this as a two-patch series:

1/2. Fix the lookup logic by introducing the match_seq parameter.
2/2. Apply the current fix on top of that change.

Thanks.