From nobody Fri Apr 26 11:30:38 2024 Received: from mail-oa1-f45.google.com (mail-oa1-f45.google.com [209.85.160.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3C22FD50B for ; Thu, 9 Mar 2023 14:50:28 +0000 (UTC) Received: by mail-oa1-f45.google.com with SMTP id 586e51a60fabf-176b48a9a05so2605604fac.0 for ; Thu, 09 Mar 2023 06:50:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares.net; s=google; t=1678373427; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:from:to:cc:subject:date:message-id :reply-to; bh=Yrosoov8wMW4bQ0IPE1nmhR+l/Rp0kl9JcSqtQe1jpE=; b=76O9ecj625aE035fR+jJca0HDYqsNoDQVIobeO4uYZKvNAy2QgeMNl8bYcvhqNILq4 KaUmQ1TBTkHrALfRRzpIlPVR897HxDLP+c4ZUMAG0+krNEo9aO35Fc/SDyMNFYbgcmjR dyyiweHsCh5H+XQBoj9eyoAp1WBdALG9g2x8W1PfGSQUHRq1AzP4TbqUc7Hxz11aJep8 R68ROACrf9mCnVCZ4EUjBc6ZYI//dy2CiaYlhrAjoXEelqFlklz/obHl0RXBMox38Gk+ dk6iRleuEAyI2ocfY1JU50FMoplFBfBhu3LSV9FcyyyVzWIOQ87t+mSNBttpVkMJQwOv iwzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678373427; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Yrosoov8wMW4bQ0IPE1nmhR+l/Rp0kl9JcSqtQe1jpE=; b=xC7kj+CoRDNdWfYUi432cDAikgR9psgFPxUfI5AhRc4GbTOXsgaorTcVatwmmFM8BK goGJ76vXSi84gnzO6kmqkRJ4qzLvQO6YWq0rl+OQ1ImMHiswfMLYB5g7st1zMFNe0Qpx cMnH1QxW8Szkj5BuPsbwOhWF74JYRGrClkNcZNzZx96vwbAxG4qlHgmCh3gpw/n9U2SV ks+0H3/yEB8h9Y5CtHYAwC8q/oLU551AZCnAXzYFM6U+b7mfA0xwpOMkwLJ2PETB3j6e +vH0APkYT4f7Ac9MDhuTuwsM8ar2UaCwClJ1n2xf4+b+f/ALz9GVuKQx0imnX7HieDdF n/SA== X-Gm-Message-State: AO0yUKXA4pbl3tuLcKK1hHygBMPLhzbZhMijyiQifxmhbvisnGyEwzFv k78Eq90cKFcvOFFIcXCUgAD88Q== X-Google-Smtp-Source: AK7set9RwNdSia6Xh6JDQSoe/HTY0sLEIPEodV0I3z7HfordCWZxGxPJMIKJbfhs028daaLmaSeE8A== X-Received: by 2002:a05:6870:65a2:b0:176:271d:2e22 with SMTP id fp34-20020a05687065a200b00176271d2e22mr2852112oab.19.1678373427133; Thu, 09 Mar 2023 06:50:27 -0800 (PST) Received: from vdi08.nix.tessares.net (static.219.156.76.144.clients.your-server.de. [144.76.156.219]) by smtp.gmail.com with ESMTPSA id ax39-20020a05687c022700b0016b0369f08fsm7351116oac.15.2023.03.09.06.50.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Mar 2023 06:50:26 -0800 (PST) From: Matthieu Baerts Date: Thu, 09 Mar 2023 15:49:57 +0100 Subject: [PATCH net v2 1/8] mptcp: fix possible deadlock in subflow_error_report Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20230227-upstream-net-20230227-mptcp-fixes-v2-1-47c2e95eada9@tessares.net> References: <20230227-upstream-net-20230227-mptcp-fixes-v2-0-47c2e95eada9@tessares.net> In-Reply-To: <20230227-upstream-net-20230227-mptcp-fixes-v2-0-47c2e95eada9@tessares.net> To: mptcp@lists.linux.dev, "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Mat Martineau , Jiang Biao , Menglong Dong , Mengen Sun , Shuah Khan , Florian Westphal Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, Matthieu Baerts , Christoph Paasch , stable@vger.kernel.org X-Mailer: b4 0.12.1 X-Developer-Signature: v=1; a=openpgp-sha256; l=1773; i=matthieu.baerts@tessares.net; h=from:subject:message-id; bh=hldf995oDj7E8lQxC4BW/Zq3Mra/hurDbKe3yAogNH0=; b=owEBbQKS/ZANAwAIAfa3gk9CaaBzAcsmYgBkCfIhTQvT//R9yYrZy+DQCBgpgC83QuOSWPCRI UqPZe1dcRiJAjMEAAEIAB0WIQToy4X3aHcFem4n93r2t4JPQmmgcwUCZAnyIQAKCRD2t4JPQmmg c3YXEACUmPPmO+kb+DzJ09sg4PSISe1YOWwSv/mfrMCBc61sXOCGf7ZOllBXYfuF0aEqMJv+EkS 7D7ElqKu505tvkp5UWykx+9kUtKboXrxB1gkoJeDuXaRxs/f5Ed/u7u+AFwtR8JV1OUHpB889g5 K2IuPvpPRLBySAx0/I625uSqqty+rN7R84G7w5DCT3yThX6ViQJn9Lby1w4rcVVA9S35+vDgL6U iAFXIjTYVbspATWOY42glSHljqgPe/zBTTbvcwuxnof+RAGcVZnVz3kqztMduVOsN83A+Z0w7qF zP23RmPdN579J9ZtLex3LgkRy31y02XZxyx4OziSNYlsgGeWu5eebTQ5FuoWhLuvDCx1i08hUyw QxSKb5DL/VBkQF4kIuz9JdybvOvQvTk1rvvIqL9hu5EagFfRPDjNsbwZgReKw2F4LNtLRlwjCmq xzRMKvZuTDstc9vn3800vHJWeS4dXlgLvBUtwjJMaQpv/mgWKgxomaEoCp2hTpP+fz0TeZaZ7dM 8lHSQQSVa1Re/N7vVfzLwO6SlS7ytLcw1Z4kHtCn3RxMvws201IwAIlAqN7/sv/0sxov4Wl3SPa sD/Lbs6h4ZCBuJUg2B9J+1sSnbnBRsPnUeFp6aA/ebjRDtD5TjWVUdHP+4a5a8+6rBh+XlXCJeB /4wzJXDSTjabKIA== X-Developer-Key: i=matthieu.baerts@tessares.net; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 From: Paolo Abeni Christoph reported a possible deadlock while the TCP stack destroys an unaccepted subflow due to an incoming reset: the MPTCP socket error path tries to acquire the msk-level socket lock while TCP still owns the listener socket accept queue spinlock, and the reverse dependency already exists in the TCP stack. Note that the above is actually a lockdep false positive, as the chain involves two separate sockets. A different per-socket lockdep key will address the issue, but such a change will be quite invasive. Instead, we can simply stop earlier the socket error handling for orphaned or unaccepted subflows, breaking the critical lockdep chain. Error handling in such a scenario is a no-op. Reported-and-tested-by: Christoph Paasch Fixes: 15cc10453398 ("mptcp: deliver ssk errors to msk") Cc: stable@vger.kernel.org Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/355 Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts Signed-off-by: Matthieu Baerts --- net/mptcp/subflow.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c index 4ae1a7304cf0..5070dc33675d 100644 --- a/net/mptcp/subflow.c +++ b/net/mptcp/subflow.c @@ -1432,6 +1432,13 @@ static void subflow_error_report(struct sock *ssk) { struct sock *sk =3D mptcp_subflow_ctx(ssk)->conn; =20 + /* bail early if this is a no-op, so that we avoid introducing a + * problematic lockdep dependency between TCP accept queue lock + * and msk socket spinlock + */ + if (!sk->sk_socket) + return; + mptcp_data_lock(sk); if (!sock_owned_by_user(sk)) __mptcp_error_report(sk); --=20 2.39.2 From nobody Fri Apr 26 11:30:38 2024 Received: from mail-oa1-f50.google.com (mail-oa1-f50.google.com [209.85.160.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BC1F4D50B for ; Thu, 9 Mar 2023 14:50:35 +0000 (UTC) Received: by mail-oa1-f50.google.com with SMTP id 586e51a60fabf-176eae36feaso2530977fac.6 for ; Thu, 09 Mar 2023 06:50:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares.net; s=google; t=1678373435; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:from:to:cc:subject:date:message-id :reply-to; bh=Axm/mEYsFxl88X8LxAlaC741Co4mFhokJO1H5zDTC1A=; b=zo+zvy/eR8rvYN8U6vA3WCW/8G9ZTGoFt5OdaQAB9KYAZ9u/MvpCyv5YYaqs24IMCu X21Y02MemMy4MF+VLA+cQaMZ7eS2QiVudFZCuOS6vGvril8CAIvEYNsPP6deN0vX7V6r RSciDtkWMHtNYqErgjAZfxhHBKvzBtj/nnBpy/1DTfCQNdTIz9YyU3BEr15KXsyi01VG FE4HqlZQ92gfKYN3DQCN9jbVBiKhCEz9yl1Hw+fVDISOnZoqirwSXf92ftkDUVRxD/NU NUcg9/fN7G47/LrDZqmwZQ7Z18HEye8KasvSS9sGi9k9dU9KxAjgmDZXkdZ/yB3AXOaX PFfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678373435; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Axm/mEYsFxl88X8LxAlaC741Co4mFhokJO1H5zDTC1A=; b=mHevZjvFdCC+JB79BSvWbr40tb6c8eSYw3Ndwy70nbbcUmTuuqEDhYOs7KObV5DlW/ nx4c6HoC2jHSDnD9tt4zr4txQD7yjR/ONkCjTDx9mIhODOB1SHNUS7EqssCxLVesYAce on5XyvoIfPHpgZdqL/AkemUp5AnOsCbN9l+xwBvzGvsI9v5XI40ENsph+A+Khr79zW1N k5dl34KVEEfPbk//B9wN7ofuHrYGh5V00CihJk++pnmQ1trFDI8zTH3YD9qAJ+0BkbLm 2jFsTMGcqkjnblml1MKrRnsNRLgu5zgCWh7eEGqwpGC8mFNWpkNTdVJnDt+FdcgpN88o gPnA== X-Gm-Message-State: AO0yUKVMQslAsWiOYiXEftRYWhXkqIbIq7ovYSfl4LTbEdwajIlij9Pu QpW2ociwRHbnxeQlf4zMBUKJ5w== X-Google-Smtp-Source: AK7set9juLhEoEB1xSU9mBYPmwAnG6JJNXp3wN/PuEWT7REYhe3oHgqS9gJVsbpvcKbaIZHttoiiYw== X-Received: by 2002:a05:6870:82a9:b0:16e:223b:1922 with SMTP id q41-20020a05687082a900b0016e223b1922mr12985082oae.15.1678373435231; Thu, 09 Mar 2023 06:50:35 -0800 (PST) Received: from vdi08.nix.tessares.net (static.219.156.76.144.clients.your-server.de. [144.76.156.219]) by smtp.gmail.com with ESMTPSA id ax39-20020a05687c022700b0016b0369f08fsm7351116oac.15.2023.03.09.06.50.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Mar 2023 06:50:34 -0800 (PST) From: Matthieu Baerts Date: Thu, 09 Mar 2023 15:49:58 +0100 Subject: [PATCH net v2 2/8] mptcp: refactor passive socket initialization Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20230227-upstream-net-20230227-mptcp-fixes-v2-2-47c2e95eada9@tessares.net> References: <20230227-upstream-net-20230227-mptcp-fixes-v2-0-47c2e95eada9@tessares.net> In-Reply-To: <20230227-upstream-net-20230227-mptcp-fixes-v2-0-47c2e95eada9@tessares.net> To: mptcp@lists.linux.dev, "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Mat Martineau , Jiang Biao , Menglong Dong , Mengen Sun , Shuah Khan , Florian Westphal Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, Matthieu Baerts , stable@vger.kernel.org, Christoph Paasch X-Mailer: b4 0.12.1 X-Developer-Signature: v=1; a=openpgp-sha256; l=5101; i=matthieu.baerts@tessares.net; h=from:subject:message-id; bh=ver9M0p/LeGtx9UIbzbhioiM0gxqrJ/KIvxjL/g/J6o=; b=owEBbQKS/ZANAwAIAfa3gk9CaaBzAcsmYgBkCfIhsDZDaZWYi9As+hGXqc0WzNSDKUQxICz2p zrcih1ESUyJAjMEAAEIAB0WIQToy4X3aHcFem4n93r2t4JPQmmgcwUCZAnyIQAKCRD2t4JPQmmg c26aEAC81nEv5iyWLUuzRiz/oUj3dHjVdWTC1E8hH1V2CTPFJD/UDFToSGq2AVanRXd0A5srCnd HyQWhITDG79fuYoT2qFjqm+xC5UT1Arm0fM+jjYbjBJZMumtv39X86LSo/sDRKCg0zR4THjVpgV pp1zotcEPYVM/1XT34wmldimJPe4NxhoDLwtU/aq9qeJoW20b83bGv8Kdo4IkyCb89vRTxBQwct /ikV4zkt+RFEHRo1B2Ym2yNm4iSv/t/FVnGn6hjxTN8OkPLYFOAuZ2+XIDU5pdgrh8i6hBsI+Ea BJSyN8iB7VN5AhtfJ0g5GaJiJe0Pc2T2BV/iKwlXoqy1qme7PZk6wkH+BQLeBDzVWOe8LSP5gtQ pDpZky1PGmrYp1L06F/VYf+TMOdRr0Cr/vavBjLHGpsdjTyS9DABle+va1pn0ktKSHvoK7a6kZk Vod9KzV47JlJOGtmwo2NIq7xXBjXwbFgtP31kpsRSsLghUI6VukVURRYi88FQWHOU90m1x1pLez Fpfc8v35Nmm4+nUwqdAVq1MTeHf3ZHMKoHFvVo6ZW2EPmdzF4lIMmzGVhBFLiEzwBF67QmJr+PJ 8ZwRGeas1QOJ5KIhpwo6upYn0YZDsw3Q7FTTiqPslTnGh84ST1OP1qTh2BTjlhhZc6Gv7u88hTj HlCBtB80Et7RP5w== X-Developer-Key: i=matthieu.baerts@tessares.net; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 From: Paolo Abeni After commit 30e51b923e43 ("mptcp: fix unreleased socket in accept queue") unaccepted msk sockets go throu complete shutdown, we don't need anymore to delay inserting the first subflow into the subflow lists. The reference counting deserve some extra care, as __mptcp_close() is unaware of the request socket linkage to the first subflow. Please note that this is more a refactoring than a fix but because this modification is needed to include other corrections, see the following commits. Then a Fixes tag has been added here to help the stable team. Fixes: 30e51b923e43 ("mptcp: fix unreleased socket in accept queue") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts Tested-by: Christoph Paasch Signed-off-by: Matthieu Baerts --- net/mptcp/protocol.c | 17 ----------------- net/mptcp/subflow.c | 27 +++++++++++++++++++++------ 2 files changed, 21 insertions(+), 23 deletions(-) diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index 3ad9c46202fc..447641d34c2c 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -825,7 +825,6 @@ static bool __mptcp_finish_join(struct mptcp_sock *msk,= struct sock *ssk) if (sk->sk_socket && !ssk->sk_socket) mptcp_sock_graft(ssk, sk->sk_socket); =20 - mptcp_propagate_sndbuf((struct sock *)msk, ssk); mptcp_sockopt_sync_locked(msk, ssk); return true; } @@ -3708,22 +3707,6 @@ static int mptcp_stream_accept(struct socket *sock, = struct socket *newsock, =20 lock_sock(newsk); =20 - /* PM/worker can now acquire the first subflow socket - * lock without racing with listener queue cleanup, - * we can notify it, if needed. - * - * Even if remote has reset the initial subflow by now - * the refcnt is still at least one. - */ - subflow =3D mptcp_subflow_ctx(msk->first); - list_add(&subflow->node, &msk->conn_list); - sock_hold(msk->first); - if (mptcp_is_fully_established(newsk)) - mptcp_pm_fully_established(msk, msk->first, GFP_KERNEL); - - mptcp_rcv_space_init(msk, msk->first); - mptcp_propagate_sndbuf(newsk, msk->first); - /* set ssk->sk_socket of accept()ed flows to mptcp socket. * This is needed so NOSPACE flag can be set from tcp stack. */ diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c index 5070dc33675d..a631a5e6fc7b 100644 --- a/net/mptcp/subflow.c +++ b/net/mptcp/subflow.c @@ -397,6 +397,12 @@ void mptcp_subflow_reset(struct sock *ssk) struct mptcp_subflow_context *subflow =3D mptcp_subflow_ctx(ssk); struct sock *sk =3D subflow->conn; =20 + /* mptcp_mp_fail_no_response() can reach here on an already closed + * socket + */ + if (ssk->sk_state =3D=3D TCP_CLOSE) + return; + /* must hold: tcp_done() could drop last reference on parent */ sock_hold(sk); =20 @@ -750,6 +756,7 @@ static struct sock *subflow_syn_recv_sock(const struct = sock *sk, struct mptcp_options_received mp_opt; bool fallback, fallback_is_fatal; struct sock *new_msk =3D NULL; + struct mptcp_sock *owner; struct sock *child; =20 pr_debug("listener=3D%p, req=3D%p, conn=3D%p", listener, req, listener->c= onn); @@ -824,6 +831,8 @@ static struct sock *subflow_syn_recv_sock(const struct = sock *sk, ctx->setsockopt_seq =3D listener->setsockopt_seq; =20 if (ctx->mp_capable) { + owner =3D mptcp_sk(new_msk); + /* this can't race with mptcp_close(), as the msk is * not yet exposted to user-space */ @@ -832,14 +841,14 @@ static struct sock *subflow_syn_recv_sock(const struc= t sock *sk, /* record the newly created socket as the first msk * subflow, but don't link it yet into conn_list */ - WRITE_ONCE(mptcp_sk(new_msk)->first, child); + WRITE_ONCE(owner->first, child); =20 /* new mpc subflow takes ownership of the newly * created mptcp socket */ mptcp_sk(new_msk)->setsockopt_seq =3D ctx->setsockopt_seq; - mptcp_pm_new_connection(mptcp_sk(new_msk), child, 1); - mptcp_token_accept(subflow_req, mptcp_sk(new_msk)); + mptcp_pm_new_connection(owner, child, 1); + mptcp_token_accept(subflow_req, owner); ctx->conn =3D new_msk; new_msk =3D NULL; =20 @@ -847,15 +856,21 @@ static struct sock *subflow_syn_recv_sock(const struc= t sock *sk, * uses the correct data */ mptcp_copy_inaddrs(ctx->conn, child); + mptcp_propagate_sndbuf(ctx->conn, child); + + mptcp_rcv_space_init(owner, child); + list_add(&ctx->node, &owner->conn_list); + sock_hold(child); =20 /* with OoO packets we can reach here without ingress * mpc option */ - if (mp_opt.suboptions & OPTION_MPTCP_MPC_ACK) + if (mp_opt.suboptions & OPTION_MPTCP_MPC_ACK) { mptcp_subflow_fully_established(ctx, &mp_opt); + mptcp_pm_fully_established(owner, child, GFP_ATOMIC); + ctx->pm_notified =3D 1; + } } else if (ctx->mp_join) { - struct mptcp_sock *owner; - owner =3D subflow_req->msk; if (!owner) { subflow_add_reset_reason(skb, MPTCP_RST_EPROHIBIT); --=20 2.39.2 From nobody Fri Apr 26 11:30:38 2024 Received: from mail-oa1-f42.google.com (mail-oa1-f42.google.com [209.85.160.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 21735D50B for ; Thu, 9 Mar 2023 14:50:44 +0000 (UTC) Received: by mail-oa1-f42.google.com with SMTP id 586e51a60fabf-17638494edbso2508690fac.10 for ; Thu, 09 Mar 2023 06:50:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares.net; s=google; t=1678373444; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:from:to:cc:subject:date:message-id :reply-to; bh=KCav8n7jkp43mQRU7lpslVP05Xar/ItVmiODndOYZMw=; b=WSI3vNjzQG2b936rSfurigaEkD4Ad1gTjcobR8M6aclMPpBQjEFlZLjUyIyTT90moP b2zL4AT5jsljFAiU7mdJEK1XzGTgRhS9i28I4ioSqiB077DJqZA79om209/MIGV6Ayzd GIUCGnswiObcgVIzbFyqv5Jj18/dyff13TNiwHlD8ddxv0/lNoCtLtfzTCDI1qg+Dz+E pFL6QTXAujPVrRcdE9SP6MHp5YCuXiCfI4JzVcYNvEfdB24QiS7L2Jwhs0SUldK9m+dg JKC6QzXCmIACzfEZ2W5g1hWYt++aIuUlhOB55r7GlOUCHLugJr1K9VOqFlj/Yg57rG4I LQVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678373444; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=KCav8n7jkp43mQRU7lpslVP05Xar/ItVmiODndOYZMw=; b=AeH1VkX9pXkhwhzgiLKjktiyXWGKj3+6oPfSSVIe5Q07DC+1DLryEusHQEoQDSce+2 k4iSuiSvOGuq0jeRiPn0PdLKOvXjAgerMO02XdthXC651zXdie+dEIBelyEKABqzsEfk ZYBCBPSGMsjkTcutQ9o+8Aqv/oOn57a4QnI6QKgiP9jJw5aiKY42jfNapNjfYwGPbQH0 r7vYGLDSxb9npAccN5nP/SI3IPRnMfCTT9UyBBRkEqoGacRb/b7jkG7GejpMUVBDjdzD B96WJWJymkYl1Y82JocKiL2IoYEjwvsWhXElbDzgq22R7MAs23fi8P6j9ZNrxtGNzX+0 9Org== X-Gm-Message-State: AO0yUKXPr+rLEpcFpimeR3C9wXZSabbXw0U4ChE/p8LsljFehugQlcJd 92+62kYoESZ7rIEX7wVJGjGckg== X-Google-Smtp-Source: AK7set9D8Msdx9oaqx9+JkD7S5KM8+ys9dDeMR3lMv0c8ulEC0+AmnRqOr4IwzgaVlo6I7qS/j0m7g== X-Received: by 2002:a05:6870:c14c:b0:16e:86ec:581c with SMTP id g12-20020a056870c14c00b0016e86ec581cmr13811494oad.58.1678373443360; Thu, 09 Mar 2023 06:50:43 -0800 (PST) Received: from vdi08.nix.tessares.net (static.219.156.76.144.clients.your-server.de. [144.76.156.219]) by smtp.gmail.com with ESMTPSA id ax39-20020a05687c022700b0016b0369f08fsm7351116oac.15.2023.03.09.06.50.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Mar 2023 06:50:43 -0800 (PST) From: Matthieu Baerts Date: Thu, 09 Mar 2023 15:49:59 +0100 Subject: [PATCH net v2 3/8] mptcp: use the workqueue to destroy unaccepted sockets Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20230227-upstream-net-20230227-mptcp-fixes-v2-3-47c2e95eada9@tessares.net> References: <20230227-upstream-net-20230227-mptcp-fixes-v2-0-47c2e95eada9@tessares.net> In-Reply-To: <20230227-upstream-net-20230227-mptcp-fixes-v2-0-47c2e95eada9@tessares.net> To: mptcp@lists.linux.dev, "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Mat Martineau , Jiang Biao , Menglong Dong , Mengen Sun , Shuah Khan , Florian Westphal Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, Matthieu Baerts , stable@vger.kernel.org, Christoph Paasch X-Mailer: b4 0.12.1 X-Developer-Signature: v=1; a=openpgp-sha256; l=9213; i=matthieu.baerts@tessares.net; h=from:subject:message-id; bh=Ox33y+imkgkIsAvT8c5rK/ze9qxNE1B+VCk2y577suc=; b=owEBbQKS/ZANAwAIAfa3gk9CaaBzAcsmYgBkCfIhCbRLd+ujCCwY2vTvOgHq4M/4hLhfRy7Ig IBvurLGtMSJAjMEAAEIAB0WIQToy4X3aHcFem4n93r2t4JPQmmgcwUCZAnyIQAKCRD2t4JPQmmg c8s3D/wN0eZt/4ktj1E1sDswK0h7c0Vquk7Yvp+BwZehetzoB9Fl75HkscxSX/+ip/mtW5r3OKC B0XYYD0bEtAdtTu6DEC5Rf6d04sGV5JmSOVKR9+duBU/fivOX38YAz7dvKfh37EolO16HiXlkgv ZDRNncToBI7BBa/0tJWt5/nEUX4CSNBGxsz1951YObv+0RJtJWu8BtIzsXoGdvJSuoDatq/lbV7 Wx2uql8GbY5wtj3YEfyhjACi6FuOFsN/sZa0ueaufjCYwDsj7kHE1rTag7iN7ajo70HevHxBf6I w/HIZ0RRucqwqosg/wD43s4nBGV1bnwLi1Oevdzl3/eAgzpDCbx3ZFXJrsnDdRTDNvzIqsLFaZk nTyTDD4+Sq7rL31hyahW5QNS+9XtndH8qcSYekFoKLh3YuH381BP8+wQt7OeuEb6uaBGtkCf1qo c3K1SGJV2NysT8VSOjtNs5ZNwpusd+QM49upV2+9Gwf7/6jx4ISrTYu/ttMA0y8s5R69S8M6Uvv iV4rz/3QGfEMcRs0PK+kL7ugHtThPZkyqN1gDWgU1VAwjaDOfmcXQVh1suwOAOjvK9SvlCa1uyy MEtoOYt16pIXQ4NA+AS3oosoS6iHwlz41GFk60ZZX/XEH6wH7K4sEQCtJLcNQwgzaZMfteJqay7 u1YXaivLkEw0PBA== X-Developer-Key: i=matthieu.baerts@tessares.net; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 From: Paolo Abeni Christoph reported a UaF at token lookup time after having refactored the passive socket initialization part: BUG: KASAN: use-after-free in __token_bucket_busy+0x253/0x260 Read of size 4 at addr ffff88810698d5b0 by task syz-executor653/3198 CPU: 1 PID: 3198 Comm: syz-executor653 Not tainted 6.2.0-rc59af4eaa31c1f6= c00c8f1e448ed99a45c66340dd5 #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-= gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x6e/0x91 print_report+0x16a/0x46f kasan_report+0xad/0x130 __token_bucket_busy+0x253/0x260 mptcp_token_new_connect+0x13d/0x490 mptcp_connect+0x4ed/0x860 __inet_stream_connect+0x80e/0xd90 tcp_sendmsg_fastopen+0x3ce/0x710 mptcp_sendmsg+0xff1/0x1a20 inet_sendmsg+0x11d/0x140 __sys_sendto+0x405/0x490 __x64_sys_sendto+0xdc/0x1b0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc We need to properly clean-up all the paired MPTCP-level resources and be sure to release the msk last, even when the unaccepted subflow is destroyed by the TCP internals via inet_child_forget(). We can re-use the existing MPTCP_WORK_CLOSE_SUBFLOW infra, explicitly checking that for the critical scenario: the closed subflow is the MPC one, the msk is not accepted and eventually going through full cleanup. With such change, __mptcp_destroy_sock() is always called on msk sockets, even on accepted ones. We don't need anymore to transiently drop one sk reference at msk clone time. Please note this commit depends on the parent one: mptcp: refactor passive socket initialization Fixes: 58b09919626b ("mptcp: create msk early") Cc: stable@vger.kernel.org Reported-and-tested-by: Christoph Paasch Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/347 Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts Signed-off-by: Matthieu Baerts --- net/mptcp/protocol.c | 40 ++++++++++++++++++++++++++++++---------- net/mptcp/protocol.h | 5 ++++- net/mptcp/subflow.c | 17 ++++++++++++----- 3 files changed, 46 insertions(+), 16 deletions(-) diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index 447641d34c2c..2a2093d61835 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -2342,7 +2342,6 @@ static void __mptcp_close_ssk(struct sock *sk, struct= sock *ssk, goto out; } =20 - sock_orphan(ssk); subflow->disposable =3D 1; =20 /* if ssk hit tcp_done(), tcp_cleanup_ulp() cleared the related ops @@ -2350,7 +2349,20 @@ static void __mptcp_close_ssk(struct sock *sk, struc= t sock *ssk, * reference owned by msk; */ if (!inet_csk(ssk)->icsk_ulp_ops) { + WARN_ON_ONCE(!sock_flag(ssk, SOCK_DEAD)); kfree_rcu(subflow, rcu); + } else if (msk->in_accept_queue && msk->first =3D=3D ssk) { + /* if the first subflow moved to a close state, e.g. due to + * incoming reset and we reach here before inet_child_forget() + * the TCP stack could later try to close it via + * inet_csk_listen_stop(), or deliver it to the user space via + * accept(). + * We can't delete the subflow - or risk a double free - nor let + * the msk survive - or will be leaked in the non accept scenario: + * fallback and let TCP cope with the subflow cleanup. + */ + WARN_ON_ONCE(sock_flag(ssk, SOCK_DEAD)); + mptcp_subflow_drop_ctx(ssk); } else { /* otherwise tcp will dispose of the ssk and subflow ctx */ if (ssk->sk_state =3D=3D TCP_LISTEN) { @@ -2398,9 +2410,10 @@ static unsigned int mptcp_sync_mss(struct sock *sk, = u32 pmtu) return 0; } =20 -static void __mptcp_close_subflow(struct mptcp_sock *msk) +static void __mptcp_close_subflow(struct sock *sk) { struct mptcp_subflow_context *subflow, *tmp; + struct mptcp_sock *msk =3D mptcp_sk(sk); =20 might_sleep(); =20 @@ -2414,7 +2427,15 @@ static void __mptcp_close_subflow(struct mptcp_sock = *msk) if (!skb_queue_empty_lockless(&ssk->sk_receive_queue)) continue; =20 - mptcp_close_ssk((struct sock *)msk, ssk, subflow); + mptcp_close_ssk(sk, ssk, subflow); + } + + /* if the MPC subflow has been closed before the msk is accepted, + * msk will never be accept-ed, close it now + */ + if (!msk->first && msk->in_accept_queue) { + sock_set_flag(sk, SOCK_DEAD); + inet_sk_state_store(sk, TCP_CLOSE); } } =20 @@ -2623,6 +2644,9 @@ static void mptcp_worker(struct work_struct *work) __mptcp_check_send_data_fin(sk); mptcp_check_data_fin(sk); =20 + if (test_and_clear_bit(MPTCP_WORK_CLOSE_SUBFLOW, &msk->flags)) + __mptcp_close_subflow(sk); + /* There is no point in keeping around an orphaned sk timedout or * closed, but we need the msk around to reply to incoming DATA_FIN, * even if it is orphaned and in FIN_WAIT2 state @@ -2638,9 +2662,6 @@ static void mptcp_worker(struct work_struct *work) } } =20 - if (test_and_clear_bit(MPTCP_WORK_CLOSE_SUBFLOW, &msk->flags)) - __mptcp_close_subflow(msk); - if (test_and_clear_bit(MPTCP_WORK_RTX, &msk->flags)) __mptcp_retrans(sk); =20 @@ -3078,6 +3099,7 @@ struct sock *mptcp_sk_clone(const struct sock *sk, msk->local_key =3D subflow_req->local_key; msk->token =3D subflow_req->token; msk->subflow =3D NULL; + msk->in_accept_queue =3D 1; WRITE_ONCE(msk->fully_established, false); if (mp_opt->suboptions & OPTION_MPTCP_CSUMREQD) WRITE_ONCE(msk->csum_enabled, true); @@ -3095,8 +3117,7 @@ struct sock *mptcp_sk_clone(const struct sock *sk, security_inet_csk_clone(nsk, req); bh_unlock_sock(nsk); =20 - /* keep a single reference */ - __sock_put(nsk); + /* note: the newly allocated socket refcount is 2 now */ return nsk; } =20 @@ -3152,8 +3173,6 @@ static struct sock *mptcp_accept(struct sock *sk, int= flags, int *err, goto out; } =20 - /* acquire the 2nd reference for the owning socket */ - sock_hold(new_mptcp_sock); newsk =3D new_mptcp_sock; MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_MPCAPABLEPASSIVEACK); } else { @@ -3704,6 +3723,7 @@ static int mptcp_stream_accept(struct socket *sock, s= truct socket *newsock, struct sock *newsk =3D newsock->sk; =20 set_bit(SOCK_CUSTOM_SOCKOPT, &newsock->flags); + msk->in_accept_queue =3D 0; =20 lock_sock(newsk); =20 diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h index 61fd8eabfca2..3a2db1b862dd 100644 --- a/net/mptcp/protocol.h +++ b/net/mptcp/protocol.h @@ -295,7 +295,8 @@ struct mptcp_sock { u8 recvmsg_inq:1, cork:1, nodelay:1, - fastopening:1; + fastopening:1, + in_accept_queue:1; int connect_flags; struct work_struct work; struct sk_buff *ooo_last_skb; @@ -666,6 +667,8 @@ void mptcp_subflow_set_active(struct mptcp_subflow_cont= ext *subflow); =20 bool mptcp_subflow_active(struct mptcp_subflow_context *subflow); =20 +void mptcp_subflow_drop_ctx(struct sock *ssk); + static inline void mptcp_subflow_tcp_fallback(struct sock *sk, struct mptcp_subflow_context *ctx) { diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c index a631a5e6fc7b..932a3e0eb22d 100644 --- a/net/mptcp/subflow.c +++ b/net/mptcp/subflow.c @@ -699,9 +699,10 @@ static bool subflow_hmac_valid(const struct request_so= ck *req, =20 static void mptcp_force_close(struct sock *sk) { - /* the msk is not yet exposed to user-space */ + /* the msk is not yet exposed to user-space, and refcount is 2 */ inet_sk_state_store(sk, TCP_CLOSE); sk_common_release(sk); + sock_put(sk); } =20 static void subflow_ulp_fallback(struct sock *sk, @@ -717,7 +718,7 @@ static void subflow_ulp_fallback(struct sock *sk, mptcp_subflow_ops_undo_override(sk); } =20 -static void subflow_drop_ctx(struct sock *ssk) +void mptcp_subflow_drop_ctx(struct sock *ssk) { struct mptcp_subflow_context *ctx =3D mptcp_subflow_ctx(ssk); =20 @@ -823,7 +824,7 @@ static struct sock *subflow_syn_recv_sock(const struct = sock *sk, =20 if (new_msk) mptcp_copy_inaddrs(new_msk, child); - subflow_drop_ctx(child); + mptcp_subflow_drop_ctx(child); goto out; } =20 @@ -914,7 +915,7 @@ static struct sock *subflow_syn_recv_sock(const struct = sock *sk, return child; =20 dispose_child: - subflow_drop_ctx(child); + mptcp_subflow_drop_ctx(child); tcp_rsk(req)->drop_req =3D true; inet_csk_prepare_for_destroy_sock(child); tcp_done(child); @@ -1866,7 +1867,6 @@ void mptcp_subflow_queue_clean(struct sock *listener_= sk, struct sock *listener_s struct sock *sk =3D (struct sock *)msk; bool do_cancel_work; =20 - sock_hold(sk); lock_sock_nested(sk, SINGLE_DEPTH_NESTING); next =3D msk->dl_next; msk->first =3D NULL; @@ -1954,6 +1954,13 @@ static void subflow_ulp_release(struct sock *ssk) * when the subflow is still unaccepted */ release =3D ctx->disposable || list_empty(&ctx->node); + + /* inet_child_forget() does not call sk_state_change(), + * explicitly trigger the socket close machinery + */ + if (!release && !test_and_set_bit(MPTCP_WORK_CLOSE_SUBFLOW, + &mptcp_sk(sk)->flags)) + mptcp_schedule_work(sk); sock_put(sk); } =20 --=20 2.39.2 From nobody Fri Apr 26 11:30:38 2024 Received: from mail-oa1-f47.google.com (mail-oa1-f47.google.com [209.85.160.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 51A16D50B for ; Thu, 9 Mar 2023 14:50:54 +0000 (UTC) Received: by mail-oa1-f47.google.com with SMTP id 586e51a60fabf-176d93cd0daso2551668fac.4 for ; Thu, 09 Mar 2023 06:50:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares.net; s=google; t=1678373453; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:from:to:cc:subject:date:message-id :reply-to; bh=DxqskVtJzbIDGhzu4xtaacI8mLtuQFfHH0D65SJmQ6Q=; b=pArBNs6h4QTYazYH+8c9+6JnBPZgnyIhg1ZSIqF04ep0j9xmjSIoSjc36Qycsn5EpL 2ttfrlU7mmksQomKTjSLcyRClbUvjmXgHETuIazaTfi/JQDPl1JxPSYrXaWNYMkOzW4B eFAoSt41BqwV9Mbyz7Y+nDtpGL+lQxTOkAr8tJtMqy8NfOaBA4uKMx+An4ijxzYBDs6C tg4EC7scAn/SzfY/9oEVCIAwDG7Nwun39g3dJ7/zS2RUDLE6yRwKBorfyFBG9l8zvT9r 2O/y45kQzGOX4YCUdtAPgMz2hfN9r9g/XXr1Zrub1YcsC9Ii3SBrVa1TT8tu+Omfqnsq uT2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678373453; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=DxqskVtJzbIDGhzu4xtaacI8mLtuQFfHH0D65SJmQ6Q=; b=owxjjhybo4qbRgJXpLc1nuAk8oq7F7DrIXP0R4al31zfsHnUZkEgee4RlOeEXsVPnV 5P2r+6K8wXRyCl63eRSTbwCJfNLRKhtQ9wYb9R4GMapkxTxzX+heWLaNP7mp3vU2H4gv ZtYjU3Mc8E3F7m4Rlrf8lDka7cv6HqV5fvAN6smY8VuBwVvM6u3ZRJ/cF6SB1Bg0mcCH 06e48HeWaB3KbF22Xjad7guLqFo6GnK6ei4V3BtRqfNtbTmd+68mUO1jEPNY5FPQ/JLQ tzshpvMzdKXROBnhkcpqk+lqrF9TaJwt46S7U5toQGqGwdlmsF9Ci8c8GVC4eCOWvDQd J/Gw== X-Gm-Message-State: AO0yUKW6RYtSrC4spzhfPuyZ580mvq9mSC5Z7yv6eKqoFLiNTVIOGhHt +K5ER7Lufhbqr3m6mydnSZhoMg== X-Google-Smtp-Source: AK7set9IJUNm2y2ShEgf1fjwo+Dgv5UjmgWBSgKsrwzJdGz2QXRBI5g6tH5cZYXbIAXdiqK1fKiKkQ== X-Received: by 2002:a05:6870:5703:b0:172:7220:a9eb with SMTP id k3-20020a056870570300b001727220a9ebmr12734986oap.8.1678373451935; Thu, 09 Mar 2023 06:50:51 -0800 (PST) Received: from vdi08.nix.tessares.net (static.219.156.76.144.clients.your-server.de. [144.76.156.219]) by smtp.gmail.com with ESMTPSA id ax39-20020a05687c022700b0016b0369f08fsm7351116oac.15.2023.03.09.06.50.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Mar 2023 06:50:51 -0800 (PST) From: Matthieu Baerts Date: Thu, 09 Mar 2023 15:50:00 +0100 Subject: [PATCH net v2 4/8] mptcp: fix UaF in listener shutdown Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20230227-upstream-net-20230227-mptcp-fixes-v2-4-47c2e95eada9@tessares.net> References: <20230227-upstream-net-20230227-mptcp-fixes-v2-0-47c2e95eada9@tessares.net> In-Reply-To: <20230227-upstream-net-20230227-mptcp-fixes-v2-0-47c2e95eada9@tessares.net> To: mptcp@lists.linux.dev, "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Mat Martineau , Jiang Biao , Menglong Dong , Mengen Sun , Shuah Khan , Florian Westphal Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, Matthieu Baerts , stable@vger.kernel.org, Christoph Paasch X-Mailer: b4 0.12.1 X-Developer-Signature: v=1; a=openpgp-sha256; l=6328; i=matthieu.baerts@tessares.net; h=from:subject:message-id; bh=TJIewReJ/yOGpWt8keCbB5zXjaxYZOxSV1Zl9q3p0x0=; b=owEBbQKS/ZANAwAIAfa3gk9CaaBzAcsmYgBkCfIhBXsVeZCD4caj3mT+fPvYXxeBAkoAALrYI VKKDez3LnaJAjMEAAEIAB0WIQToy4X3aHcFem4n93r2t4JPQmmgcwUCZAnyIQAKCRD2t4JPQmmg c434D/4ikPybhwE5pZT5G2x9W5cfhIZMvjQZCPWoFP/zVpZzEwfsvhO9MrQJWFYQp7MvVYoAQTb eaRCqSZ+A2wTz5lTrEncsw8gy9/HpkActlxZd+FDGQtzC62dOaSjfDrlorYTwRfSRlPNxTotccl mYqyZ4lypkVi33xZ4HjoJCEfrG9s7l6UYMB7tD8LW4Dpq2MmIxhO/YfWwTa+ZMhv8beOQLP2JdR wIk+4h/h6DP8amWByt6W0YwCjf9Uv5T2s1NdpQiB5oD/5KJVSeB0jWZeTi9Tx5aeuYP7YC1NrLK xL10fq7FUkBuYaxK/IrZCUx4Dtu02utlbIqdW9ikCiQ4PYqsyFsXqMxTEFklkg+MqqEnldZA6K0 5JtD+pvuxHnGxmZc0R8Dw5CXS/2k1fYWcRNcIabqA5LNnq/UNJctAYX6RUTkWMEXXANT6QzSMXc sbGfPwtdihdqt9qkJtCC1Y2BUlxPOwpvPM9p4EF0Y3roAfCMFTmC+wm5MqzXPYqL+ls19+/UsIs ziaYhAG2T4VNHjUVMRQSFHZtSaD+kMuBbFI06CQxvXmkD2XA6TamC7G5D1EMcZx/mOqz7x9oxFt YmJRKONECgBspQvh4DkBigKPENXh76Jc1jWQre0P1rK9udR/M17ZvDDbSr3o9N8a6h8LNnKfhqn 3bFby3ULhxVe1oQ== X-Developer-Key: i=matthieu.baerts@tessares.net; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 From: Paolo Abeni As reported by Christoph after having refactored the passive socket initialization, the mptcp listener shutdown path is prone to an UaF issue. BUG: KASAN: use-after-free in _raw_spin_lock_bh+0x73/0xe0 Write of size 4 at addr ffff88810cb23098 by task syz-executor731/1266 CPU: 1 PID: 1266 Comm: syz-executor731 Not tainted 6.2.0-rc59af4eaa31c1f6= c00c8f1e448ed99a45c66340dd5 #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-= gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x6e/0x91 print_report+0x16a/0x46f kasan_report+0xad/0x130 kasan_check_range+0x14a/0x1a0 _raw_spin_lock_bh+0x73/0xe0 subflow_error_report+0x6d/0x110 sk_error_report+0x3b/0x190 tcp_disconnect+0x138c/0x1aa0 inet_child_forget+0x6f/0x2e0 inet_csk_listen_stop+0x209/0x1060 __mptcp_close_ssk+0x52d/0x610 mptcp_destroy_common+0x165/0x640 mptcp_destroy+0x13/0x80 __mptcp_destroy_sock+0xe7/0x270 __mptcp_close+0x70e/0x9b0 mptcp_close+0x2b/0x150 inet_release+0xe9/0x1f0 __sock_release+0xd2/0x280 sock_close+0x15/0x20 __fput+0x252/0xa20 task_work_run+0x169/0x250 exit_to_user_mode_prepare+0x113/0x120 syscall_exit_to_user_mode+0x1d/0x40 do_syscall_64+0x48/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc The msk grace period can legitly expire in between the last reference count dropped in mptcp_subflow_queue_clean() and the later eventual access in inet_csk_listen_stop() After the previous patch we don't need anymore special-casing msk listener socket cleanup: the mptcp worker will process each of the unaccepted msk sockets. Just drop the now unnecessary code. Please note this commit depends on the two parent ones: mptcp: refactor passive socket initialization mptcp: use the workqueue to destroy unaccepted sockets Fixes: 6aeed9045071 ("mptcp: fix race on unaccepted mptcp sockets") Cc: stable@vger.kernel.org Reported-and-tested-by: Christoph Paasch Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/346 Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts Signed-off-by: Matthieu Baerts --- net/mptcp/protocol.c | 7 ++--- net/mptcp/protocol.h | 1 - net/mptcp/subflow.c | 72 ------------------------------------------------= ---- 3 files changed, 2 insertions(+), 78 deletions(-) diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index 2a2093d61835..60b23b2716c4 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -2365,12 +2365,9 @@ static void __mptcp_close_ssk(struct sock *sk, struc= t sock *ssk, mptcp_subflow_drop_ctx(ssk); } else { /* otherwise tcp will dispose of the ssk and subflow ctx */ - if (ssk->sk_state =3D=3D TCP_LISTEN) { - tcp_set_state(ssk, TCP_CLOSE); - mptcp_subflow_queue_clean(sk, ssk); - inet_csk_listen_stop(ssk); + if (ssk->sk_state =3D=3D TCP_LISTEN) mptcp_event_pm_listener(ssk, MPTCP_EVENT_LISTENER_CLOSED); - } + __tcp_close(ssk, 0); =20 /* close acquired an extra ref */ diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h index 3a2db1b862dd..339a6f072989 100644 --- a/net/mptcp/protocol.h +++ b/net/mptcp/protocol.h @@ -629,7 +629,6 @@ void mptcp_close_ssk(struct sock *sk, struct sock *ssk, struct mptcp_subflow_context *subflow); void __mptcp_subflow_send_ack(struct sock *ssk); void mptcp_subflow_reset(struct sock *ssk); -void mptcp_subflow_queue_clean(struct sock *sk, struct sock *ssk); void mptcp_sock_graft(struct sock *sk, struct socket *parent); struct socket *__mptcp_nmpc_socket(const struct mptcp_sock *msk); bool __mptcp_close(struct sock *sk, long timeout); diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c index 932a3e0eb22d..9c57575df84c 100644 --- a/net/mptcp/subflow.c +++ b/net/mptcp/subflow.c @@ -1826,78 +1826,6 @@ static void subflow_state_change(struct sock *sk) } } =20 -void mptcp_subflow_queue_clean(struct sock *listener_sk, struct sock *list= ener_ssk) -{ - struct request_sock_queue *queue =3D &inet_csk(listener_ssk)->icsk_accept= _queue; - struct mptcp_sock *msk, *next, *head =3D NULL; - struct request_sock *req; - - /* build a list of all unaccepted mptcp sockets */ - spin_lock_bh(&queue->rskq_lock); - for (req =3D queue->rskq_accept_head; req; req =3D req->dl_next) { - struct mptcp_subflow_context *subflow; - struct sock *ssk =3D req->sk; - struct mptcp_sock *msk; - - if (!sk_is_mptcp(ssk)) - continue; - - subflow =3D mptcp_subflow_ctx(ssk); - if (!subflow || !subflow->conn) - continue; - - /* skip if already in list */ - msk =3D mptcp_sk(subflow->conn); - if (msk->dl_next || msk =3D=3D head) - continue; - - msk->dl_next =3D head; - head =3D msk; - } - spin_unlock_bh(&queue->rskq_lock); - if (!head) - return; - - /* can't acquire the msk socket lock under the subflow one, - * or will cause ABBA deadlock - */ - release_sock(listener_ssk); - - for (msk =3D head; msk; msk =3D next) { - struct sock *sk =3D (struct sock *)msk; - bool do_cancel_work; - - lock_sock_nested(sk, SINGLE_DEPTH_NESTING); - next =3D msk->dl_next; - msk->first =3D NULL; - msk->dl_next =3D NULL; - - do_cancel_work =3D __mptcp_close(sk, 0); - release_sock(sk); - if (do_cancel_work) { - /* lockdep will report a false positive ABBA deadlock - * between cancel_work_sync and the listener socket. - * The involved locks belong to different sockets WRT - * the existing AB chain. - * Using a per socket key is problematic as key - * deregistration requires process context and must be - * performed at socket disposal time, in atomic - * context. - * Just tell lockdep to consider the listener socket - * released here. - */ - mutex_release(&listener_sk->sk_lock.dep_map, _RET_IP_); - mptcp_cancel_work(sk); - mutex_acquire(&listener_sk->sk_lock.dep_map, - SINGLE_DEPTH_NESTING, 0, _RET_IP_); - } - sock_put(sk); - } - - /* we are still under the listener msk socket lock */ - lock_sock_nested(listener_ssk, SINGLE_DEPTH_NESTING); -} - static int subflow_ulp_init(struct sock *sk) { struct inet_connection_sock *icsk =3D inet_csk(sk); --=20 2.39.2 From nobody Fri Apr 26 11:30:38 2024 Received: from mail-oa1-f42.google.com (mail-oa1-f42.google.com [209.85.160.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 383D7D50B for ; Thu, 9 Mar 2023 14:51:04 +0000 (UTC) Received: by mail-oa1-f42.google.com with SMTP id 586e51a60fabf-17638494edbso2509688fac.10 for ; Thu, 09 Mar 2023 06:51:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares.net; s=google; t=1678373464; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:from:to:cc:subject:date:message-id :reply-to; bh=jgeAurw5MQ6tabjrQfM6Jio39u1LTtRrLhUhKbdYExw=; b=Cg0nkh6N2mnjRz9oTVqPcSePKZ79I3DFoF4oYbVoCbQoneyBkvdhLSvDYAoWoj+ygm QUWczEK5ebPtwC2CpLRzNAM5BpXz6MDMkQ22ipB8a8cufp2P7GPp/SfzWbDp2hhgQ9lN O7hSOmFAtCpo1po6Am5b53KS2MU/Sno8zilT1TY1kTUwjC48l6kLME6HZ4NHy/WUU+YJ wyf/LHSilpyCnkBaY9L7hX0gWhCauTZyubwK1AJ2gDAHBLAjTWWr5PzytSQTzanr79CO eHrF/38A6oN4JvMCOZQjt2A+88k3w0gSQWZ65EECf5s+TxC3mubzRg+sAgOaSh9tMbZ4 DAgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678373464; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=jgeAurw5MQ6tabjrQfM6Jio39u1LTtRrLhUhKbdYExw=; b=p6B1RygNm5UJy/oGAc5AjijIRDdNFFKNExDSmATiveemRPQ72CtbANmLRsWCtVb1sr BoQCrl9ZlJ/aLhJQ6QTVJ/bxXO/rEZhfM7Qaew5qGbZgfZSiOobiViCCDGWNGO8MuLKu ydxtyM5bXdVtakxTXCd+4SrudtV5kE00vVpkll4y8+jTvI+b8YNcX84XIMTnjSW3NETf gVLvkoGMtZz7ADw9wEf4T6t4mvt+Wv+w/1t0hZnhmSfpH44Bb89XVc530uf7b+uNMfp0 eU8cUyTI9jkSA0Bm9zys6GZSVqnyS0cnm7TNczle7DgCWvmh1frB0gSntOVEMrYsWQT3 YjRA== X-Gm-Message-State: AO0yUKWGofAX5NPvPXHzF4BzX/4s7QKNZwlB1Fj8TzcLjVzKGmOdM1jP dp1wy9/pEQoPe0EdV3/nKWZs8g== X-Google-Smtp-Source: AK7set/94Yfw73tXkB/5sbOJy675nwgFppBnXZoL/g1os/ge410otddzBvv06nAljQJn1rFoSiNbeA== X-Received: by 2002:a05:6870:8090:b0:163:97bd:814d with SMTP id q16-20020a056870809000b0016397bd814dmr15161728oab.27.1678373461384; Thu, 09 Mar 2023 06:51:01 -0800 (PST) Received: from vdi08.nix.tessares.net (static.219.156.76.144.clients.your-server.de. [144.76.156.219]) by smtp.gmail.com with ESMTPSA id ax39-20020a05687c022700b0016b0369f08fsm7351116oac.15.2023.03.09.06.50.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Mar 2023 06:51:01 -0800 (PST) From: Matthieu Baerts Date: Thu, 09 Mar 2023 15:50:01 +0100 Subject: [PATCH net v2 5/8] selftests: mptcp: userspace pm: fix printed values Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20230227-upstream-net-20230227-mptcp-fixes-v2-5-47c2e95eada9@tessares.net> References: <20230227-upstream-net-20230227-mptcp-fixes-v2-0-47c2e95eada9@tessares.net> In-Reply-To: <20230227-upstream-net-20230227-mptcp-fixes-v2-0-47c2e95eada9@tessares.net> To: mptcp@lists.linux.dev, "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Mat Martineau , Jiang Biao , Menglong Dong , Mengen Sun , Shuah Khan , Florian Westphal Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, Matthieu Baerts , stable@vger.kernel.org, Geliang Tang X-Mailer: b4 0.12.1 X-Developer-Signature: v=1; a=openpgp-sha256; l=1019; i=matthieu.baerts@tessares.net; h=from:subject:message-id; bh=mevXKVwguJYVDj5NKWsKg6dJCzPlEP7cAxuF4rctlYE=; b=owEBbQKS/ZANAwAIAfa3gk9CaaBzAcsmYgBkCfIhuwuqoRrEHcNzQiGfZqVb0x2N6M0XyYmps ACVicEN6GaJAjMEAAEIAB0WIQToy4X3aHcFem4n93r2t4JPQmmgcwUCZAnyIQAKCRD2t4JPQmmg c1d5D/9ElMBnE7hj2nLsVC/JHhBeGhtZgtA8SuE7YnP5mypX/lRaQU2u2LxrS41LX7WB2sC+r98 sZXYmpxByWVZuYaKxRLYah2t/cT4Payeo3YALz8YusFmFvTH+XjD83L3RF74Tdar2HLxZO/ltbh IOwUYL+Q5kK9SzgMGcs3iqHDgLIPxXua3VIaoISTBGFb/IVG5NrnePIjX9DHC540aFJhEzbTNmP u13iD4qiUk35/Hl0CmOiENKHCFKPXsX3sB+/FhMg7F4U1COL+lpZlI4kIJFn8V+jYWj2+uZQewy YcNYyj5nX2I2dN09nvqKFRavFdu4HQ/s5+l2dD2Z08Lo+FQhJs3YTBVYSENI+c/yv6+UHF5Gtl0 ujVKYf0QMQHl3biQesi7hQ3TKNH6ul7jflAKDBkhhMVsRnXnp/rCWTGKgKYc5MqWR4ZahAiasQA ERDILknXE8YWKXj0aoUoeYZusBm35XIeVHAQASkKUZi6XqC23I6RxHXQsWTyVfMf39Q8mvfxVct iVL4ZVpecMjlw9jYEEo60rbPeoPq7ns2KjXaF3mW/5sfp2434uVL8LoWAbKnGGVB2kiGZSij2Up WTCwCJJxWfc8wsY/2XNMT70Fll1AlS3UzIq1WzqXG+BFHQFwlJ88cGBzhLTNtUQkINroO0QvNSL Qi1YMRHJjDLp0Uw== X-Developer-Key: i=matthieu.baerts@tessares.net; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 In case of errors, the printed message had the expected and the seen value inverted. This patch simply correct the order: first the expected value, then the one that has been seen. Fixes: 10d4273411be ("selftests: mptcp: userspace: print error details if a= ny") Cc: stable@vger.kernel.org Acked-by: Geliang Tang Signed-off-by: Matthieu Baerts --- tools/testing/selftests/net/mptcp/userspace_pm.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/net/mptcp/userspace_pm.sh b/tools/test= ing/selftests/net/mptcp/userspace_pm.sh index 66c5be25c13d..48e52f995a98 100755 --- a/tools/testing/selftests/net/mptcp/userspace_pm.sh +++ b/tools/testing/selftests/net/mptcp/userspace_pm.sh @@ -240,7 +240,7 @@ check_expected_one() fi =20 stdbuf -o0 -e0 printf "\tExpected value for '%s': '%s', got '%s'.\n" \ - "${var}" "${!var}" "${!exp}" + "${var}" "${!exp}" "${!var}" return 1 } =20 --=20 2.39.2 From nobody Fri Apr 26 11:30:38 2024 Received: from mail-oa1-f42.google.com (mail-oa1-f42.google.com [209.85.160.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0711CD50B for ; Thu, 9 Mar 2023 14:51:13 +0000 (UTC) Received: by mail-oa1-f42.google.com with SMTP id 586e51a60fabf-17638494edbso2510198fac.10 for ; Thu, 09 Mar 2023 06:51:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares.net; s=google; t=1678373472; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:from:to:cc:subject:date:message-id :reply-to; bh=7aVI4e2OdlOYVuMUfrd7oCECSdqBtHFzJOKgjTLxG8Y=; b=tGsVthprhw/reHeu0kXsKQ3G4aAujKF/o6r1dMxPdSzLo1GiCnsDQ0KP9zqhy4akt+ ukd3KSdcnCj5w52bz0EPCD3kMAKw5C3kJrMv5cwpujHZdeqj0rbb1f4oTlWaPgoie+Fi oqPWTGV7PEU+54huXmLOmPhHK9oZpLdrMFhz5v/1emVPZghgLVbJwEnmNuyF1WtChcS0 kfeqgsjC7b22IuH3T+k+40V+QXjkkeG0yKo+dMARhKjOqsRoGsUwOZwVSXLT1dk7xng0 HWI4UHtO28QAfPRmmLK0F28oPs0iOV1/3ETbHznFLB/PNBCR1vSv0sR6kYQmnLM54Ji0 j0qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678373472; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=7aVI4e2OdlOYVuMUfrd7oCECSdqBtHFzJOKgjTLxG8Y=; b=pl1mWl/yeGIVO5LH4co3SCvQOIi6e3yPIhC7vvdOqNYO80W5qEhMgPDEdwalBjLeLq hfT+Rl5H3v/MjIDaTxWLFA75usPybx5pBZi+HBFg+C7QtWahBq5UaRnLzNuG7NF/VtnG /U8ip+CWSABYTbtI7K+JumWhZ3WCmGKPrs/SLtWxQQY006cCQepJSd5olp8DNnt/VRVX E7HeT4qA7gm3BBBd8/HQvMp/9A5a5pfU5PGy28As7KkBsW7WfwRWNvopVRhR5d3sxWFZ Z08ElXm5T4yBRlIZobEmZzNjA8f9QPVUmDEGfIy+o1DpfW3+PwbpbUKtiZVfVixdu+zK +rHA== X-Gm-Message-State: AO0yUKVtpptMZl/DBSAgF4obFhpCpt/mrWoNky87RZOHtsruhiOox4NC kilzMv/M2XxBKCxTw/WxysZWxA== X-Google-Smtp-Source: AK7set/BxsPcC+kHi85xoG6nN7cO/XktZA2laWYayamgxbuDGcc1aRzL0J6Z81vp8brLfoyc73CXcA== X-Received: by 2002:a05:6870:ac1e:b0:172:a40f:5ff7 with SMTP id kw30-20020a056870ac1e00b00172a40f5ff7mr13766983oab.15.1678373470400; Thu, 09 Mar 2023 06:51:10 -0800 (PST) Received: from vdi08.nix.tessares.net (static.219.156.76.144.clients.your-server.de. [144.76.156.219]) by smtp.gmail.com with ESMTPSA id ax39-20020a05687c022700b0016b0369f08fsm7351116oac.15.2023.03.09.06.51.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Mar 2023 06:51:10 -0800 (PST) From: Matthieu Baerts Date: Thu, 09 Mar 2023 15:50:02 +0100 Subject: [PATCH net v2 6/8] mptcp: add ro_after_init for tcp{,v6}_prot_override Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20230227-upstream-net-20230227-mptcp-fixes-v2-6-47c2e95eada9@tessares.net> References: <20230227-upstream-net-20230227-mptcp-fixes-v2-0-47c2e95eada9@tessares.net> In-Reply-To: <20230227-upstream-net-20230227-mptcp-fixes-v2-0-47c2e95eada9@tessares.net> To: mptcp@lists.linux.dev, "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Mat Martineau , Jiang Biao , Menglong Dong , Mengen Sun , Shuah Khan , Florian Westphal Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, Matthieu Baerts , Geliang Tang , stable@vger.kernel.org X-Mailer: b4 0.12.1 X-Developer-Signature: v=1; a=openpgp-sha256; l=1660; i=matthieu.baerts@tessares.net; h=from:subject:message-id; bh=jwqxBRvOjpFpJeOhBbQNAMdCMsCRiyb+3+BlXnlrYos=; b=owEBbQKS/ZANAwAIAfa3gk9CaaBzAcsmYgBkCfIhvNkzCHxVtYQT3XvqIPehwKS4POj6L7ylM Oq6BtJKQB2JAjMEAAEIAB0WIQToy4X3aHcFem4n93r2t4JPQmmgcwUCZAnyIQAKCRD2t4JPQmmg c/zGEACqL6+KKaSjgkuLXw9CX+Naqdq9ZO96zwpEXD95zrKUK4O8JaHHSLNyzKq2NksdN2iRwhZ 7oj2fI8FvM8nguDeHJiGuVFewPfMJBtz+DW4sqf/+Sq4TUlZCMNwIpizXW153YGZL9JE5B5xqYs FFWqRTBMSRlVyubNDj6heuregejJ2Vwvf6voTRb83e67ueY9fGG8BPhVxl224aZcEK0Q7ToDRVp Utrkr7QFId9CYkRdXst2qrWcM/QsLbJJ21IwgXQuepgOB2tMtbYkAjpWfRieUuhTPCDrqw078+L hVg8gr6iFvBWecQUE6bQpqM20Tfpq2OxyYpHTzPBy2+Z3ZBsNeNlru/VBXHOyDbRk24z3XqWYXz MueoJdJ4o1rFgpLYgrYGsnTDX228EOkG0vKs8ZAaXSFZ5IPGX7shVBsH/IZ84fdhAMtivP/WAXI 6bkTzSB8sH0D9c/kQWd0CFwHPHBg/c75C9Jz+uGEUXjUJebvqaXEMgkA/lI9IGsCc+b9cn/55qw /HXEUy7bjKFRJKFuVtetgL8+hn9tANC0g4uF8DfInATFIch2IUGR6zgkMq5hiHOuT3um7qRkvm1 Q0WbH6u3/OdBAO8L+hMiKx+ALYG2iNcXBinxP4k47I8XBgux36FUMdargEBkINqaglBHHLeBSkC q1JUskp+9rIuAyQ== X-Developer-Key: i=matthieu.baerts@tessares.net; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 From: Geliang Tang Add __ro_after_init labels for the variables tcp_prot_override and tcpv6_prot_override, just like other variables adjacent to them, to indicate that they are initialised from the init hooks and no writes occur afterwards. Fixes: b19bc2945b40 ("mptcp: implement delegated actions") Cc: stable@vger.kernel.org Fixes: 51fa7f8ebf0e ("mptcp: mark ops structures as ro_after_init") Signed-off-by: Geliang Tang Reviewed-by: Matthieu Baerts Signed-off-by: Matthieu Baerts --- net/mptcp/subflow.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c index 9c57575df84c..2aadc8733369 100644 --- a/net/mptcp/subflow.c +++ b/net/mptcp/subflow.c @@ -628,7 +628,7 @@ static struct request_sock_ops mptcp_subflow_v6_request= _sock_ops __ro_after_init static struct tcp_request_sock_ops subflow_request_sock_ipv6_ops __ro_afte= r_init; static struct inet_connection_sock_af_ops subflow_v6_specific __ro_after_i= nit; static struct inet_connection_sock_af_ops subflow_v6m_specific __ro_after_= init; -static struct proto tcpv6_prot_override; +static struct proto tcpv6_prot_override __ro_after_init; =20 static int subflow_v6_conn_request(struct sock *sk, struct sk_buff *skb) { @@ -926,7 +926,7 @@ static struct sock *subflow_syn_recv_sock(const struct = sock *sk, } =20 static struct inet_connection_sock_af_ops subflow_specific __ro_after_init; -static struct proto tcp_prot_override; +static struct proto tcp_prot_override __ro_after_init; =20 enum mapping_status { MAPPING_OK, --=20 2.39.2 From nobody Fri Apr 26 11:30:38 2024 Received: from mail-oa1-f47.google.com (mail-oa1-f47.google.com [209.85.160.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C8818D50B for ; Thu, 9 Mar 2023 14:51:19 +0000 (UTC) Received: by mail-oa1-f47.google.com with SMTP id 586e51a60fabf-176d93cd0daso2553154fac.4 for ; Thu, 09 Mar 2023 06:51:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares.net; s=google; t=1678373479; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:from:to:cc:subject:date:message-id :reply-to; bh=jzm/x7TOjLOgi7CwKs4YCZ1LBGnvx2xB9lo0ysTnYvA=; b=H4PVIGDTl6WnZIPkjc+EFidMIA/6sgQ8MLWYqnDcXuN8hA6Qfw54b0x9GKQmCs98R6 OVI2quuA1TxFEl6utPmQQ41Xik06vszzJ4jDmqkCQyWducURrSp6FHKyJ+d8aCBeDD7e WFnRNbfgRhHTpDKtFmaeMOF64z4wjvyfYKXFuvMBHnT+X//VITbr8y0e65CEvs1u4cbV Vae9aasikEPye6Moacpey80/g3Z1PmWsL4kjOjmt54pD5HewSgVMFDphEBt26OCG71Bp 5lKP4wnu6U6vj/ghMghMU0qvCuhwhRh+rJX3TRGGntswCK7rdtsFc8r1QaxMgzmMGe2m CPbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678373479; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=jzm/x7TOjLOgi7CwKs4YCZ1LBGnvx2xB9lo0ysTnYvA=; b=aUqbudqcj05HZMlZJzZZIe0nUCKfQxIkEyRm+clCZuB7QqZkpdhVIYmt+/oua2i76q eFASvcs+Oe29q4fwdJHLdrkpZlLGwnHZ5upheUDliiGKNGtQZQkIiNLhsPMN/qWCp4Lu QqnE4oBwG5iT+fcmxVwYMZs0P28UPM3xRsZIFR7Tf/2fzFwgGsPUW03Ck/EHYUrQeX2R 92hPnRuvQQM6urk26XBKYdQeAugsMKIo8f8qGBsO6ZHekP2pOtlGeZgghDr/jehhTfK0 1ypm1dnGaS+hWEgSkokOPDXEgSbwWM5RAsbhHS2QKSvJGoDnK+khWZAe+wLS5DxKJ3oi fTsQ== X-Gm-Message-State: AO0yUKXUHKuWn0mX5F332J20IQc7slzujC9EBnstHgNV6c8qlp5wP9Af NL8YrZxL8beXO18X3GLcO7zWzw== X-Google-Smtp-Source: AK7set9GO0zxZyi7mefBy78H7fTBv+s+weKltD5HfFkitvia0cbS4wrAj2uYkuZMQfIaQ5I5Z1fUeQ== X-Received: by 2002:a05:6871:285:b0:172:45ff:6293 with SMTP id i5-20020a056871028500b0017245ff6293mr13952175oae.26.1678373478812; Thu, 09 Mar 2023 06:51:18 -0800 (PST) Received: from vdi08.nix.tessares.net (static.219.156.76.144.clients.your-server.de. [144.76.156.219]) by smtp.gmail.com with ESMTPSA id ax39-20020a05687c022700b0016b0369f08fsm7351116oac.15.2023.03.09.06.51.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Mar 2023 06:51:18 -0800 (PST) From: Matthieu Baerts Date: Thu, 09 Mar 2023 15:50:03 +0100 Subject: [PATCH net v2 7/8] mptcp: avoid setting TCP_CLOSE state twice Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20230227-upstream-net-20230227-mptcp-fixes-v2-7-47c2e95eada9@tessares.net> References: <20230227-upstream-net-20230227-mptcp-fixes-v2-0-47c2e95eada9@tessares.net> In-Reply-To: <20230227-upstream-net-20230227-mptcp-fixes-v2-0-47c2e95eada9@tessares.net> To: mptcp@lists.linux.dev, "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Mat Martineau , Jiang Biao , Menglong Dong , Mengen Sun , Shuah Khan , Florian Westphal Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, Matthieu Baerts , stable@vger.kernel.org X-Mailer: b4 0.12.1 X-Developer-Signature: v=1; a=openpgp-sha256; l=963; i=matthieu.baerts@tessares.net; h=from:subject:message-id; bh=YhQrvwLHpqWFuACAI0OELxustQ1PVT1SBUl80EUsJ68=; b=owEBbQKS/ZANAwAIAfa3gk9CaaBzAcsmYgBkCfIhVzi8yguOmSTvdyb8Fy2uvF6oIcbmQZxef 8MjZTpDu0OJAjMEAAEIAB0WIQToy4X3aHcFem4n93r2t4JPQmmgcwUCZAnyIQAKCRD2t4JPQmmg cxQSEAC4h1EXetyTEuncZ+ZrvfqSoNohT6csTHKoNAOLWuSclc59xfJaNgQIAwPM7xwuUWM7W2U exMVLsI/GsR40waIDVGGUMRg5xCaLmv7KbImOzKLMLkKmRrWMxh91KMu40MCX28+AciHyVE0wfy hechXKwj8Y7kKHbbXUci4IzgwKQB0yHzMbBokX5cgdUdtsnLR2S5PPA3Vf8Aab9YuKYoUZG+aEz hxvIRyHAhH3sxN5tFr7+ulbbV6dCHORkjvVEpl2D4WYfNcmDnDzOdSFE4TgylW9TSed+5rSn+na SVZFWh1RG35f2lY4WMBxUC2RcEdtvchCEtyAh/ap2a083hgL+1mbzpcWBh5osPhXDXbhmWlcrIp BJaNNIANTekYvltIiNBs3hKyb0uefUG004sa7HZ0hSB+GZ8eEOp+NAYciFhicjK2sGRIb0Pp4ZE XG9laaTdW56tm/lh1jYVKY6clGMg7AfRcOpfZmfaa44esDWF1F4/4oCp2608iWNZEjo3a5I6yfk LvaforUNuJR5142U+zVtKkwc8X3xKzYwUn+JfNHCgem/AZn8JoMN0+yk6MkYWQ0sX6Vx6Z8sloO qb0+x87j//OOxFenXNscRCMYVBH0iGpDvu5pu7UQdpIxGtNNOAjwCyu0oq77pTlmOhBNWKJy42M WHNWz+uJ35COdTw== X-Developer-Key: i=matthieu.baerts@tessares.net; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 tcp_set_state() is called from tcp_done() already. There is then no need to first set the state to TCP_CLOSE, then call tcp_done(). Fixes: d582484726c4 ("mptcp: fix fallback for MP_JOIN subflows") Cc: stable@vger.kernel.org Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/362 Acked-by: Paolo Abeni Signed-off-by: Matthieu Baerts --- net/mptcp/subflow.c | 1 - 1 file changed, 1 deletion(-) diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c index 2aadc8733369..a0041360ee9d 100644 --- a/net/mptcp/subflow.c +++ b/net/mptcp/subflow.c @@ -406,7 +406,6 @@ void mptcp_subflow_reset(struct sock *ssk) /* must hold: tcp_done() could drop last reference on parent */ sock_hold(sk); =20 - tcp_set_state(ssk, TCP_CLOSE); tcp_send_active_reset(ssk, GFP_ATOMIC); tcp_done(ssk); if (!test_and_set_bit(MPTCP_WORK_CLOSE_SUBFLOW, &mptcp_sk(sk)->flags) && --=20 2.39.2 From nobody Fri Apr 26 11:30:38 2024 Received: from mail-oa1-f47.google.com (mail-oa1-f47.google.com [209.85.160.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BE4A8D50B for ; Thu, 9 Mar 2023 14:51:28 +0000 (UTC) Received: by mail-oa1-f47.google.com with SMTP id 586e51a60fabf-176d93cd0daso2553583fac.4 for ; Thu, 09 Mar 2023 06:51:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares.net; s=google; t=1678373488; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:from:to:cc:subject:date:message-id :reply-to; bh=Hmy3PkPHQ2u3OS0v9qWvPRQmIDrYZcauNq0B9Zz8Ptw=; b=75S4M1/anGft2wOuhmMfIB2P5gXujxapU5TSo4ZG6/cMhcGqvW3htpmJHpBs8faCf8 W4TXN3jKZ7vKY46xq/Ohqw0jSxPPZTD8w70DIs3L4p0fhlcZj4v4LYNBKkFBU1mIlYiA CB/CwRmr8041sLXRxpxhIV2l3YdAExY4pOTQYpZA/k6zymLu3myyjK/Jml2Zj+caFWoG jUX6HUTKv6LRJGCEQRlwJX5jIoaWxoM34y6OEmrbyr7CupjCRi/R7n+YQhC3wtERhr1c 1+gUKRo+U4UjkGLTZMeT6WtWFAr1CC+l9MgiwsDtNvO1MRp4AKnYAywf0JMcmZrhf/IU rogw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678373488; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Hmy3PkPHQ2u3OS0v9qWvPRQmIDrYZcauNq0B9Zz8Ptw=; b=cEgxbzOSjw5XlqyKPT7Bh3MfyjLEUHJkOMSH02Ec+ikMJGsVpHgqoVCsOx6qPc1dbT HQ8shuwKkki55/yz6JoAJq2lN2wl/z/Wb9iBAPTGPMONhrf0U7PKX3RerEunk9WKRv1r ueOS07Hz5JO2ek4LVZgB6GcwFsIkut6R+/B/5HtFgcpKiDwFVjd7VeJThoJqbR0ILZfj u26AwMCbv17sMS0GCB5zjNkw+OChypRQfDDDlVl3Q0Tgn5kvUtA0r1d7wH7SAjGVnoSa EQknjnu+ibHIOYb5NkB6/AwfdKHjOMiPbl9FT/WJoyAsJsb62tVmc8Sn8WByGmIk/CD0 Wobg== X-Gm-Message-State: AO0yUKWbk6jIDwSyk/zW2j/VZkkoM+WfTQouv7bqTZPA0Lg9zFMylmVW 9I1R7y6OnRLI4SYoMcg/kxvgHg== X-Google-Smtp-Source: AK7set/Q93gXpFgSkUWy+boYAiBLU/suM/9YdzeWXiBdvjgFNz3JrdgnlUBcu4Cy6bJL/cS+yvNOfA== X-Received: by 2002:a05:6870:63a7:b0:163:58e8:77e5 with SMTP id t39-20020a05687063a700b0016358e877e5mr13797510oap.52.1678373487398; Thu, 09 Mar 2023 06:51:27 -0800 (PST) Received: from vdi08.nix.tessares.net (static.219.156.76.144.clients.your-server.de. [144.76.156.219]) by smtp.gmail.com with ESMTPSA id ax39-20020a05687c022700b0016b0369f08fsm7351116oac.15.2023.03.09.06.51.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Mar 2023 06:51:27 -0800 (PST) From: Matthieu Baerts Date: Thu, 09 Mar 2023 15:50:04 +0100 Subject: [PATCH net v2 8/8] mptcp: fix lockdep false positive in mptcp_pm_nl_create_listen_socket() Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20230227-upstream-net-20230227-mptcp-fixes-v2-8-47c2e95eada9@tessares.net> References: <20230227-upstream-net-20230227-mptcp-fixes-v2-0-47c2e95eada9@tessares.net> In-Reply-To: <20230227-upstream-net-20230227-mptcp-fixes-v2-0-47c2e95eada9@tessares.net> To: mptcp@lists.linux.dev, "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Mat Martineau , Jiang Biao , Menglong Dong , Mengen Sun , Shuah Khan , Florian Westphal Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, Matthieu Baerts , stable@vger.kernel.org, Christoph Paasch X-Mailer: b4 0.12.1 X-Developer-Signature: v=1; a=openpgp-sha256; l=2460; i=matthieu.baerts@tessares.net; h=from:subject:message-id; bh=hqAM0Pg1CL8N6FLTp05rrsEa/m98vr/X4KK/h6eveNg=; b=owEBbQKS/ZANAwAIAfa3gk9CaaBzAcsmYgBkCfIhlczjyma02ViYKD6MJ5M1VuWVHNyx+4BGF d/hvmQ7fwqJAjMEAAEIAB0WIQToy4X3aHcFem4n93r2t4JPQmmgcwUCZAnyIQAKCRD2t4JPQmmg c31kEACurErU6ZCLhi48hHRrQ9GNdmdYCPgJTdZYIMLZ7iV3AAq4Z2knWKWnK7+hx2YiFszPJ/P hYvLL71GwNTWFGKHmnhR+aGBx1ZREpAS65kS8/p5vnBRiTwFI1q7LnFDDNa80czfsBCFpR0XXgf 2fZjQRKIl/Dhw7FBdCZ2wezTqAPmGmQdRQxRtzofrlhdK2wpqerqMeqRPKLiggC3ftK7nsdcpG+ uWC/9v4WamN0SsjGPdmbgnS5i8L+Fdcr03Ynfa+5YYRYcpaMjsCFMryP+J4+ku7OnUaKV8+W4/P G2odQbe8ZsjFUiWPwp5Af1f9Zjd4A1oNYxl+IiL1pm7oTFICdecr1YvLlG7/HmodFaU4JRsGj/y XiiJps3ZdQqQneTAeEKdI459qkvYklb+7HpOUR3y8Gsj3zQzvC76nR/W8iuvDa1BeKVWAWoSMp5 Yy+IbUKK5ZMf7WFtnXoPBIkLfHjmi9XXRgA/o4o1/ADAE9aGzCs4aMxv6oxYHfzb33AT2cHb0SJ N7xXmEJujU/9pTGfCGukRGZxFehB5IPqNiRB+rqAB57yXmq7svmCpxp2uzHGAtgVRfNvjGRkIxT MusvZ77L+pYpvPpoTrOHS5RVypXW/W5l9cuyUFA+nPnYepl2BcEd5HQvPc1+U/TG85cWI/2t8SZ Y0EKjBYvBQ+BYkw== X-Developer-Key: i=matthieu.baerts@tessares.net; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 From: Paolo Abeni Christoph reports a lockdep splat in the mptcp_subflow_create_socket() error path, when such function is invoked by mptcp_pm_nl_create_listen_socket(). Such code path acquires two separates, nested socket lock, with the internal lock operation lacking the "nested" annotation. Adding that in sock_release() for mptcp's sake only could be confusing. Instead just add a new lockclass to the in-kernel msk socket, re-initializing the lockdep infra after the socket creation. Fixes: ad2171009d96 ("mptcp: fix locking for in-kernel listener creation") Cc: stable@vger.kernel.org Reported-by: Christoph Paasch Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/354 Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts Tested-by: Christoph Paasch Signed-off-by: Matthieu Baerts --- net/mptcp/pm_netlink.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/net/mptcp/pm_netlink.c b/net/mptcp/pm_netlink.c index 56628b52d100..5c8dea49626c 100644 --- a/net/mptcp/pm_netlink.c +++ b/net/mptcp/pm_netlink.c @@ -997,9 +997,13 @@ static int mptcp_pm_nl_append_new_local_addr(struct pm= _nl_pernet *pernet, return ret; } =20 +static struct lock_class_key mptcp_slock_keys[2]; +static struct lock_class_key mptcp_keys[2]; + static int mptcp_pm_nl_create_listen_socket(struct sock *sk, struct mptcp_pm_addr_entry *entry) { + bool is_ipv6 =3D sk->sk_family =3D=3D AF_INET6; int addrlen =3D sizeof(struct sockaddr_in); struct sockaddr_storage addr; struct socket *ssock; @@ -1016,6 +1020,18 @@ static int mptcp_pm_nl_create_listen_socket(struct s= ock *sk, if (!newsk) return -EINVAL; =20 + /* The subflow socket lock is acquired in a nested to the msk one + * in several places, even by the TCP stack, and this msk is a kernel + * socket: lockdep complains. Instead of propagating the _nested + * modifiers in several places, re-init the lock class for the msk + * socket to an mptcp specific one. + */ + sock_lock_init_class_and_name(newsk, + is_ipv6 ? "mlock-AF_INET6" : "mlock-AF_INET", + &mptcp_slock_keys[is_ipv6], + is_ipv6 ? "msk_lock-AF_INET6" : "msk_lock-AF_INET", + &mptcp_keys[is_ipv6]); + lock_sock(newsk); ssock =3D __mptcp_nmpc_socket(mptcp_sk(newsk)); release_sock(newsk); --=20 2.39.2