Re: [PATCH net] sctp: fix race between sctp_wait_for_connect and peeloff

Xin Long <[email protected]> Thu, 28 May 2026 09:41:51 -0400
Newsgroups org.kernel.vger.linux-sctp,org.kernel.vger.netdev
Message-ID <CADvbK_fDMF8sAPcskb_WsL3d+4gSunviSZebsFS-XxQG2HUUCA@mail.gmail.com>
On Tue, May 26, 2026 at 11:24 PM Zhenghang Xiao <[email protected]> wrote:
>
> sctp_wait_for_connect() drops and re-acquires the socket lock while
> waiting for the association to reach ESTABLISHED state. During this
> window, another thread can peeloff the association to a new socket via
> getsockopt(SCTP_SOCKOPT_PEELOFF), changing asoc->base.sk. After
> re-acquiring the old socket lock, sctp_wait_for_connect() returns
> success without noticing the migration — the caller then accesses
> the association under the wrong lock in sctp_datamsg_from_user().
>
> Add the same sk != asoc->base.sk check that sctp_wait_for_sndbuf()
> already has, returning an error if the association was migrated while
> we slept.
>
> Fixes: 668c9beb9020 ("sctp: implement assign_number for sctp_stream_interleave")
> Signed-off-by: Zhenghang Xiao <[email protected]>
> ---
>  net/sctp/socket.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> index 1d2568bb6bc2..66e12fb0c646 100644
> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@ -9403,6 +9403,8 @@ static int sctp_wait_for_connect(struct sctp_association *asoc, long *timeo_p)
>                 release_sock(sk);
>                 current_timeo = schedule_timeout(current_timeo);
>                 lock_sock(sk);
> +               if (sk != asoc->base.sk)
> +                       goto do_error;
>
>                 *timeo_p = current_timeo;
>         }
> --
> 2.50.1 (Apple Git-155)
>

Acked-by: Xin Long <[email protected]>


Note that the pre-existing issue reported in
https://sashiko.dev/#/patchset/20260527032411.60959-1-kipreyyy%40gmail.com

I don't think it exists, as the state of any of ep->asocs should not be in
CLOSED state. sctp_wait_for_connect() can only be triggered by the path
with sctp_sendmsg_new_asoc() called, not the SCTP_SENDALL path.

The reason why it doesn't return the error from 2nd sctp_wait_for_connect()
is: there's already user data enqueued at the time, we should return the
sent length to userspace even if the asoc has been peeled off.

Thanks.