From nobody Fri Dec 19 22:03:10 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3F1BC2CCC0; Fri, 18 Apr 2025 16:46:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744994769; cv=none; b=MH7ggcpGoCnrbquYBRQNBr9PllWqhfGaXc2Xom3VBdLNeFJAinVz6HYyuoK+6b8Hd6vv/3PQRlNop4+a716N1zXMKyWjv1pqlKGd4EhvU9gYveDCCskBFN7XXaQl0+Gy5ko5QFCZQqy6gFXdHkCirFU7faNklO4i9Jstz+HA0l0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744994769; c=relaxed/simple; bh=zvmUmQEZ3L3IPpPSxYc/GgRj1jb4khCovHnrM4YSWNs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=QvdmraR68//IPrWivvl9yqwpXj6BtqZboayqg0lCLXocBbXmgYhs/V/I223li3rGndCInLqMg30EkwlM20Bi/NCggqmPbl46e+Xwda1YxSZl/HplopINNSUTOXKq5htI9/tN+Dc6IyAwQjrrKvCHNjqQ/c9+cYMHga9WXhD3rVI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=FP6c0Kcy; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="FP6c0Kcy" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7AC64C4CEE2; Fri, 18 Apr 2025 16:46:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1744994769; bh=zvmUmQEZ3L3IPpPSxYc/GgRj1jb4khCovHnrM4YSWNs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=FP6c0KcySxZnxtvcuQeVvekTMsVZ6mEwV8jldXFiGkMl+cKRHCtzxdkwKeWRc7sug eyiKiOcO/7VJkYRnbwI9q1TNNok7HClYfUSPrzABiYG+9c6p1XUnI1JMOFbnnmhi5M fEZ6UT5I8i0rRSJu/FsuiJYK42vD/iYoTbr0V6vSlpkbE66TrmZn2irI44RLS/wHE4 VEDE1sc2zt/kwKwvn3Rco1KO/im50Ei4ZZfWkZzPn7bPegdWV2/ShBgLLUlBhNCkY4 9qBXIbPLp1m+IHNPi3oxUlgPeYToyLv0V1c0gRZKx/2i5GFI6Fm+B6j4/ONiRT7Ij5 8YthwBzBgXR4w== From: "Matthieu Baerts (NGI0)" To: mptcp@lists.linux.dev, stable@vger.kernel.org, gregkh@linuxfoundation.org Cc: Gang Yan , sashal@kernel.org, Paolo Abeni , "Matthieu Baerts (NGI0)" , Jakub Kicinski Subject: [PATCH 5.10.y 1/3] mptcp: fix NULL pointer in can_accept_new_subflow Date: Fri, 18 Apr 2025 18:45:58 +0200 Message-ID: <20250418164556.3926588-6-matttbe@kernel.org> X-Mailer: git-send-email 2.48.1 In-Reply-To: <20250418164556.3926588-5-matttbe@kernel.org> References: <20250418164556.3926588-5-matttbe@kernel.org> Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=3691; i=matttbe@kernel.org; h=from:subject; bh=chgQEWyhe4KcXuZhJu0HD2Y7iXhgAlkLyZRoIrX2Wog=; b=owEBbQKS/ZANAwAKAfa3gk9CaaBzAcsmYgBoAoHFcsSdzu8DpzjWPPLVlpeSV9ZwqvMVxbwUe pOSQuqkQZOJAjMEAAEKAB0WIQToy4X3aHcFem4n93r2t4JPQmmgcwUCaAKBxQAKCRD2t4JPQmmg c1RMD/oCjv7xIXemiRgEQgSSoNTFl5IYzbRiQUn4N1CdAdAx+qnSOgQPRRpk5G+9jHVwUkO1GAV FEH4qACFehxezn0rUOFwRNL87zRsC68/s75bgvb6PFDDpfYWB5Lw+4Lich+Y2/8bQuJWUYP86pq /D5o3e5jXmwRtWvqusbLy8wV7HkKsGneWnmajvk6keLLxcQGE/L7HMw49zSskglrPv9Q9qERn44 WAI8cTWC2g+5Lie7ZEs5nXqLrex0eKAHcuvHm8XOIhi6pR+TdjSXUvqXM7szIW6HUjM83JPPKxc zDkFpNSP8uUuAw/f4Th6rZekGSnLLpDrLGoYq8J/invKdNzoeaQHN8dSPmKhEnFnTifwewcTd6z yM5WmkTdfjbQPlUdIeUM/jpgFZFyzUYp8/cu6PInsVfBRNa+goSFEKPRDVrtIPg8bTffxeTkRzt l2CnI3/9lsP22MQbSbGIYYSL6/p3RUt9N5wA5ElEukldM7crTojoqSUlaayikEBkap7znPDKZeJ HT4qQZl9ye2oeP6BLGJZbCBXirxOezwWO/j/YfpEEkVUuCzg0FnWeJpy5FgzTdekRtbfB2/mPrR O3jGV+vEu40RG0V1D0d9Z163OCRI5x52HLDP8xn4Y9Dt/JlU721vyPLoZ/WyJyClqjQikgfaVPs 2qGZAWxUsZgJnxA== X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Gang Yan commit 443041deb5ef6a1289a99ed95015ec7442f141dc upstream. When testing valkey benchmark tool with MPTCP, the kernel panics in 'mptcp_can_accept_new_subflow' because subflow_req->msk is NULL. Call trace: mptcp_can_accept_new_subflow (./net/mptcp/subflow.c:63 (discriminator 4))= (P) subflow_syn_recv_sock (./net/mptcp/subflow.c:854) tcp_check_req (./net/ipv4/tcp_minisocks.c:863) tcp_v4_rcv (./net/ipv4/tcp_ipv4.c:2268) ip_protocol_deliver_rcu (./net/ipv4/ip_input.c:207) ip_local_deliver_finish (./net/ipv4/ip_input.c:234) ip_local_deliver (./net/ipv4/ip_input.c:254) ip_rcv_finish (./net/ipv4/ip_input.c:449) ... According to the debug log, the same req received two SYN-ACK in a very short time, very likely because the client retransmits the syn ack due to multiple reasons. Even if the packets are transmitted with a relevant time interval, they can be processed by the server on different CPUs concurrently). The 'subflow_req->msk' ownership is transferred to the subflow the first, and there will be a risk of a null pointer dereference here. This patch fixes this issue by moving the 'subflow_req->msk' under the `own_req =3D=3D true` conditional. Note that the !msk check in subflow_hmac_valid() can be dropped, because the same check already exists under the own_req mpj branch where the code has been moved to. Fixes: 9466a1ccebbe ("mptcp: enable JOIN requests even if cookies are in us= e") Cc: stable@vger.kernel.org Suggested-by: Paolo Abeni Signed-off-by: Gang Yan Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20250328-net-mptcp-misc-fixes-6-15-v1-1-3416= 1a482a7f@kernel.org Signed-off-by: Jakub Kicinski [ Conflict in subflow.c because commit 74c7dfbee3e1 ("mptcp: consolidate in_opt sub-options fields in a bitmask") is not in this version. The conflict is in the context, and the modification can still be applied. Note that subflow_add_reset_reason() is not needed here, because the related feature is not supported in this version. ] Signed-off-by: Matthieu Baerts (NGI0) --- net/mptcp/subflow.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c index c3434069fb0a..5403292d4473 100644 --- a/net/mptcp/subflow.c +++ b/net/mptcp/subflow.c @@ -454,8 +454,6 @@ static bool subflow_hmac_valid(const struct request_soc= k *req, =20 subflow_req =3D mptcp_subflow_rsk(req); msk =3D subflow_req->msk; - if (!msk) - return false; =20 subflow_generate_hmac(msk->remote_key, msk->local_key, subflow_req->remote_nonce, @@ -578,11 +576,8 @@ static struct sock *subflow_syn_recv_sock(const struct= sock *sk, fallback =3D true; } else if (subflow_req->mp_join) { mptcp_get_options(skb, &mp_opt); - if (!mp_opt.mp_join || !subflow_hmac_valid(req, &mp_opt) || - !mptcp_can_accept_new_subflow(subflow_req->msk)) { - SUBFLOW_REQ_INC_STATS(req, MPTCP_MIB_JOINACKMAC); + if (!mp_opt.mp_join) fallback =3D true; - } } =20 create_child: @@ -636,6 +631,12 @@ static struct sock *subflow_syn_recv_sock(const struct= sock *sk, if (!owner) goto dispose_child; =20 + if (!subflow_hmac_valid(req, &mp_opt) || + !mptcp_can_accept_new_subflow(subflow_req->msk)) { + SUBFLOW_REQ_INC_STATS(req, MPTCP_MIB_JOINACKMAC); + goto dispose_child; + } + /* move the msk reference ownership to the subflow */ subflow_req->msk =3D NULL; ctx->conn =3D (struct sock *)owner; --=20 2.48.1 From nobody Fri Dec 19 22:03:10 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 489252CCC0; Fri, 18 Apr 2025 16:46:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744994771; cv=none; b=jmDAb1HTlw3qVY097OQuYlwnmad2cLDaIYOwo5DVmVJonb4PEv9diDWk6m3V8e5kpIwcTT1SGy+r9RTWoTi6VhfhWF6DWmISuEG+4rZL+0o79f1M8CrPpA5M6um3ceSkjY0ws8TXCMxYseJ9IKTZV/GCwv7XnG+hW1s7XiEBThA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744994771; c=relaxed/simple; bh=yhXb463cFleWjagVldQcGB7V6/PW5Ec2PYCoemAhMa0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=bhIiMuXbU3/S3mbxnsGXFFHEV8Qrurnsp1SIX2js3mgd5s1Z1koPArooNFwFgu41c2RM5s2FPgfU2liMqLH9sg42iH5QdSRP6vikr2LiJKqI9JgRPsV7lzrXfzkHblZJGFloAl97mEo/fI2weX6wSNw7Tcx7q9+Fmwn/LLBBTmw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=VJJ2Vy8j; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="VJJ2Vy8j" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 84118C4CEED; Fri, 18 Apr 2025 16:46:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1744994771; bh=yhXb463cFleWjagVldQcGB7V6/PW5Ec2PYCoemAhMa0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=VJJ2Vy8j2c8gDC6RNq2SggxyzlxeS7AuBAWzWsyRNGUVCsVikirYDq0Yh2CIJavi0 Q3jMhnQTvCXC3fDLy2yN5fDfS9DiFVZjcfN7An7QWE+fLIg98lLixd6cc4zbXx7bwH 8lv2uG+Y3rko6Y5KushARBL48SYfh3xF3vn0NiCo21dPb97UmcyAkUNsbr2Q7TlARs 5sbDXG+030ougmn0v914Ti5FgZKxZVLSpRwnpKU0vTUObnMDYCuwCcnQRFTxvRdHKs YJ+lor8cyL5jIt6ZFZiZSPS7OrmB7/U6SHyKlbvfTI6EbRRCFsas+xmNtNvUw1MjAc B/Kk6S1/M6jWQ== From: "Matthieu Baerts (NGI0)" To: mptcp@lists.linux.dev, stable@vger.kernel.org, gregkh@linuxfoundation.org Cc: "Matthieu Baerts (NGI0)" , sashal@kernel.org, Geliang Tang , Simon Horman , Jakub Kicinski Subject: [PATCH 5.10.y 2/3] mptcp: only inc MPJoinAckHMacFailure for HMAC failures Date: Fri, 18 Apr 2025 18:45:59 +0200 Message-ID: <20250418164556.3926588-7-matttbe@kernel.org> X-Mailer: git-send-email 2.48.1 In-Reply-To: <20250418164556.3926588-5-matttbe@kernel.org> References: <20250418164556.3926588-5-matttbe@kernel.org> Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=1888; i=matttbe@kernel.org; h=from:subject; bh=yhXb463cFleWjagVldQcGB7V6/PW5Ec2PYCoemAhMa0=; b=owEBbQKS/ZANAwAKAfa3gk9CaaBzAcsmYgBoAoHFK8p1WO0yTZaHnvLJ7eMof6gtV2G0ngwWj z+aYcsWABeJAjMEAAEKAB0WIQToy4X3aHcFem4n93r2t4JPQmmgcwUCaAKBxQAKCRD2t4JPQmmg cyM7D/9c60LRbta3hThQ0z3N/YGzHxN4D4C1l9AoB+i23tGKMCpmbfsF87/i5GYFJumiyC81kq1 +LyC/DNpL/+WNHZwboi69NwdcFKj6uk5UA2B2szgzbid1jv0fJ2wY7N+Xk8theN4/LwmhTk5gsa WHahKJ2syAOZspBlld1nUf/kACiEjNhAkqFIQTowlakaqM2rCIYfjhoWybQwg8j2OAvtGpztaaM EkNfoQn6U8iXSeCQfxs73vHtno3Te2dDVM2YZgFRMmwnY9IYQLBeaCIxl4ccIeG8l/LKrE/CANo mZ9Bi06hjV1Kvhp6NG43Za5Bxp48vRdwdAzeDNlzcaOgV7TGsLoDf7+0ti1yrBTDxVs8yxB72cL LChUvUiP+RgX42QJAChpz+q1bUF9SFcJV1yK4OUByheApq4fJsmTLZW7Eg13vzNWZPeRPwVi0rE I5U738WS0v0zAYzxAdMceNZEz9UpFcP4rO8pH9GAYkocBmOpqogu9c/y7Lt902sTJsAHRtbwkve 3kZ84xDdS7QsDyBHf3d2XWEQ1p7CHjuZs0BlxmQDS2+8+KC+iXG+N2HKcMLM69hhH8yQ9jwLBmH Rf+ABnLnuoq3QHpuLOL8Kekn1Bs6ez32ALVzdpMHKv+oxeIukN58TjskxTxl1mRafaxNvT/z0W8 sGWnvD7D+MFKy0w== X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" commit 21c02e8272bc95ba0dd44943665c669029b42760 upstream. Recently, during a debugging session using local MPTCP connections, I noticed MPJoinAckHMacFailure was not zero on the server side. The counter was in fact incremented when the PM rejected new subflows, because the 'subflow' limit was reached. The fix is easy, simply dissociating the two cases: only the HMAC validation check should increase MPTCP_MIB_JOINACKMAC counter. Fixes: 4cf8b7e48a09 ("subflow: introduce and use mptcp_can_accept_new_subfl= ow()") Cc: stable@vger.kernel.org Reviewed-by: Geliang Tang Signed-off-by: Matthieu Baerts (NGI0) Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250407-net-mptcp-hmac-failure-mib-v1-1-3c9= ecd0a3a50@kernel.org Signed-off-by: Jakub Kicinski [ No conflicts, but subflow_add_reset_reason() is not needed is this version: the related feature is not supported in this version. ] Signed-off-by: Matthieu Baerts (NGI0) --- net/mptcp/subflow.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c index 5403292d4473..9a8d0d877bd1 100644 --- a/net/mptcp/subflow.c +++ b/net/mptcp/subflow.c @@ -631,12 +631,14 @@ static struct sock *subflow_syn_recv_sock(const struc= t sock *sk, if (!owner) goto dispose_child; =20 - if (!subflow_hmac_valid(req, &mp_opt) || - !mptcp_can_accept_new_subflow(subflow_req->msk)) { + if (!subflow_hmac_valid(req, &mp_opt)) { SUBFLOW_REQ_INC_STATS(req, MPTCP_MIB_JOINACKMAC); goto dispose_child; } =20 + if (!mptcp_can_accept_new_subflow(owner)) + goto dispose_child; + /* move the msk reference ownership to the subflow */ subflow_req->msk =3D NULL; ctx->conn =3D (struct sock *)owner; --=20 2.48.1 From nobody Fri Dec 19 22:03:10 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5E0992CCC0; Fri, 18 Apr 2025 16:46:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744994773; cv=none; b=d6ou4rp/M0ulepJDlTZi31z9ol0mXOb3n6Ace20GBrtBJnNRqUgmflX4G/3cq/ZwuFsHlZHVQQR1yC7nYyHV18Tq0oBMnZPnl4dhnkbeP3XfFL18iTglKnat0FXxsQjh2ZB8r6nzCRfi47+Q09Zx3OXI/NjcEzckHltDiT1asp0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744994773; c=relaxed/simple; bh=6Evc0IWJ/vJ/0X/51M2poyLTeZoDAbUjdzxgXD7DUb4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ohEyCkFpwmxxBc5baegvBKnUNFkJtOjrIfEiMQ89ePm5RFjK90eG+8FaCNAcO4fvpBeCcvBc18acw8YTIAOjr1CvuRPAruo9Azm+alPCji8Vb/igOaeGBGUglAzWkGci0qyyVcUPhrrew8Ovpl9PR/3Kg2rAfKJtPHmPzoDIIiE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=C8ZxL9ee; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="C8ZxL9ee" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8F5F4C4CEED; Fri, 18 Apr 2025 16:46:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1744994773; bh=6Evc0IWJ/vJ/0X/51M2poyLTeZoDAbUjdzxgXD7DUb4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=C8ZxL9eeNe0REt+QcB7FhktjhtvLAwg7sNO5d0qkYTqLEGOWfZ29F2LX4YEcjx+z9 eO9kbzPHXrAAPOMMOPQOL7QNWK7I8zvDbK3U/5tURO5qR2y84ZAefmv+tjxPVeqXe0 9Vh/PN/xDEUfIt672afWi4hl3100tDCCDaDcoIaJd4L9Zyd33slZO8FHO3oLVPlfiP 4VQcv2ynGuY8px4EBPErZc6NQzn6OgvpJLxtq+zpDb50ubpnyCA6Wqg6l6N/yhWhIX MFUptq/R5SbvQPmORxZdxjGDwiw7yilkCi8xW0q0cwl5QIedYvXyXPOBAGNPVuz8xH 8fZ5K49gNsFpQ== From: "Matthieu Baerts (NGI0)" To: mptcp@lists.linux.dev, stable@vger.kernel.org, gregkh@linuxfoundation.org Cc: "Matthieu Baerts (NGI0)" , sashal@kernel.org, Mat Martineau , Simon Horman , Paolo Abeni Subject: [PATCH 5.10.y 3/3] mptcp: sockopt: fix getting IPV6_V6ONLY Date: Fri, 18 Apr 2025 18:46:00 +0200 Message-ID: <20250418164556.3926588-8-matttbe@kernel.org> X-Mailer: git-send-email 2.48.1 In-Reply-To: <20250418164556.3926588-5-matttbe@kernel.org> References: <20250418164556.3926588-5-matttbe@kernel.org> Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=3816; i=matttbe@kernel.org; h=from:subject; bh=6Evc0IWJ/vJ/0X/51M2poyLTeZoDAbUjdzxgXD7DUb4=; b=owEBbQKS/ZANAwAKAfa3gk9CaaBzAcsmYgBoAoHFuRsWheK+lnVvPxOPIYylIEB/mI4tvq2dL 5FPeswxgW2JAjMEAAEKAB0WIQToy4X3aHcFem4n93r2t4JPQmmgcwUCaAKBxQAKCRD2t4JPQmmg c1usEACrGHdaCffCpk+7uiPeDrdCsCig60Pk8Y6irRUI0TsUXWq+ck11clX4Y4NLc3YPaCHBSnR VX27SolCNk3espOiCRVV3PI/cidUy8nkzqHoRZt7GrPqkbBop9ORQUIw5Xm5Utbu5iZSjPDgcyO acmQBMmo1wCySCYPkiiIFhkwnaLfB1qzrbKUH0QhD324aPaZu/j9+mTgagpKVVkbyU4LdOM5h7A X4rKf+w8W6KBYAhC3wtPo+8CMDeuEGGPDBKt4Bs3l5xQvEehKW5otK1MK4yENLbL47ySEKAu0P3 boAbO0z3rLPCxKL7pKFM/lUJjekOXIofdnPVLAcApf9A0YUi/NgRAq701RO/N92p8CQELZuKMAz vllVlEg1pfXAXZlaJnLSfjLZQb4JN5pO7oDpduBFqW+B4+IfBU4D1Fd0JIgOBau6LXiFxtI64+l OkpDDNn0+W0lBMilO4TFyFkUoFbD54W7vrf8EsZJW3rwQFFt026H6hDXWjuibvaFvf7C92FinDS 1QeM9Mcx8Ds9IMz97p0BFZExoXaokXPsnDLihyFcGVIOvjBmWMuNylo2nEAXks9bdDXvc2HDYlC g5XUSyaXLN2fcgj96Oopo7wSH0LGbg4P3RsM/MulZ+mDbiloHBtbXcG13azWeOOYW5dqeoM9oiE vIGIJ21tPQhujwg== X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" commit 8c39633759885b6ff85f6d96cf445560e74df5e8 upstream. When adding a socket option support in MPTCP, both the get and set parts are supposed to be implemented. IPV6_V6ONLY support for the setsockopt part has been added a while ago, but it looks like the get part got forgotten. It should have been present as a way to verify a setting has been set as expected, and not to act differently from TCP or any other socket types. Not supporting this getsockopt(IPV6_V6ONLY) blocks some apps which want to check the default value, before doing extra actions. On Linux, the default value is 0, but this can be changed with the net.ipv6.bindv6only sysctl knob. On Windows, it is set to 1 by default. So supporting the get part, like for all other socket options, is important. Everything was in place to expose it, just the last step was missing. Only new code is added to cover this specific getsockopt(), that seems safe. Fixes: c9b95a135987 ("mptcp: support IPV6_V6ONLY setsockopt") Cc: stable@vger.kernel.org Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/550 Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250314-net-mptcp-fix-data-stream-corr-sock= opt-v1-2-122dbb249db3@kernel.org Signed-off-by: Paolo Abeni [ Conflicts in sockopt.c in the context, because commit 0abdde82b163 ("mptcp: move sockopt function into a new file") is not in this release. The modifications can still be done in protocol.c without difficulties. A particularity is that the mptcp_put_int_option() helper is required, and imported from newer versions without taking the extra features introduced with them in commit 2c9e77659a0c ("mptcp: add TCP_INQ cmsg support") and commit 3b1e21eb60e8 ("mptcp: getsockopt: add support for IP_TOS"). ] Signed-off-by: Matthieu Baerts (NGI0) --- net/mptcp/protocol.c | 45 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 45 insertions(+) diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index 51b552fa392a..f33c3150e690 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -2395,6 +2395,49 @@ static int mptcp_setsockopt(struct sock *sk, int lev= el, int optname, return -EOPNOTSUPP; } =20 +static int mptcp_put_int_option(struct mptcp_sock *msk, char __user *optva= l, + int __user *optlen, int val) +{ + int len; + + if (get_user(len, optlen)) + return -EFAULT; + if (len < 0) + return -EINVAL; + + if (len < sizeof(int) && len > 0 && val >=3D 0 && val <=3D 255) { + unsigned char ucval =3D (unsigned char)val; + + len =3D 1; + if (put_user(len, optlen)) + return -EFAULT; + if (copy_to_user(optval, &ucval, 1)) + return -EFAULT; + } else { + len =3D min_t(unsigned int, len, sizeof(int)); + if (put_user(len, optlen)) + return -EFAULT; + if (copy_to_user(optval, &val, len)) + return -EFAULT; + } + + return 0; +} + +static int mptcp_getsockopt_v6(struct mptcp_sock *msk, int optname, + char __user *optval, int __user *optlen) +{ + struct sock *sk =3D (void *)msk; + + switch (optname) { + case IPV6_V6ONLY: + return mptcp_put_int_option(msk, optval, optlen, + sk->sk_ipv6only); + } + + return -EOPNOTSUPP; +} + static int mptcp_getsockopt(struct sock *sk, int level, int optname, char __user *optval, int __user *option) { @@ -2415,6 +2458,8 @@ static int mptcp_getsockopt(struct sock *sk, int leve= l, int optname, if (ssk) return tcp_getsockopt(ssk, level, optname, optval, option); =20 + if (level =3D=3D SOL_IPV6) + return mptcp_getsockopt_v6(msk, optname, optval, option); return -EOPNOTSUPP; } =20 --=20 2.48.1