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

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/[email protected]?part=1
---
--- Patch [1]: [PATCH net v2] sctp: fix stream->outcnt underflow on duplicate RECONF responses ---
commit 9a827b81b27b219603b09c1f04c9dbc9a6dd2368
Author: Jun Yang <[email protected]>

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.