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.