[PATCH 5.10.y 0/3] mptcp: fix recent failed backports

[PATCH 5.10.y 0/3] mptcp: fix recent failed backports

[Matthieu Baerts (NGI0)]

Greg recently reported 3 patches that could not be applied without
conflicts in v5.10:

 - 443041deb5ef ("mptcp: fix NULL pointer in can_accept_new_subflow")
 - 21c02e8272bc ("mptcp: only inc MPJoinAckHMacFailure for HMAC failures")
 - 8c3963375988 ("mptcp: sockopt: fix getting IPV6_V6ONLY")

Conflicts have been resolved, and documented in each patch.

Gang Yan (1):
  mptcp: fix NULL pointer in can_accept_new_subflow

Matthieu Baerts (NGI0) (2):
  mptcp: only inc MPJoinAckHMacFailure for HMAC failures
  mptcp: sockopt: fix getting IPV6_V6ONLY

 net/mptcp/protocol.c | 45 ++++++++++++++++++++++++++++++++++++++++++++
 net/mptcp/subflow.c  | 15 +++++++++------
 2 files changed, 54 insertions(+), 6 deletions(-)

-- 
2.48.1

[PATCH 5.10.y 1/3] mptcp: fix NULL pointer in can_accept_new_subflow

[Matthieu Baerts (NGI0)]

From: Gang Yan <yangang@kylinos.cn>

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 == 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 use")
Cc: stable@vger.kernel.org
Suggested-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Gang Yan <yangang@kylinos.cn>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20250328-net-mptcp-misc-fixes-6-15-v1-1-34161a482a7f@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
[ 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) <matttbe@kernel.org>
---
 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_sock *req,
 
 	subflow_req = mptcp_subflow_rsk(req);
 	msk = subflow_req->msk;
-	if (!msk)
-		return false;
 
 	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 = 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 = true;
-		}
 	}
 
 create_child:
@@ -636,6 +631,12 @@ static struct sock *subflow_syn_recv_sock(const struct sock *sk,
 			if (!owner)
 				goto dispose_child;
 
+			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 = NULL;
 			ctx->conn = (struct sock *)owner;
-- 
2.48.1

[PATCH 5.10.y 2/3] mptcp: only inc MPJoinAckHMacFailure for HMAC failures

[Matthieu Baerts (NGI0)]

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_subflow()")
Cc: stable@vger.kernel.org
Reviewed-by: Geliang Tang <geliang@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20250407-net-mptcp-hmac-failure-mib-v1-1-3c9ecd0a3a50@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
[ 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) <matttbe@kernel.org>
---
 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 struct sock *sk,
 			if (!owner)
 				goto dispose_child;
 
-			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;
 			}
 
+			if (!mptcp_can_accept_new_subflow(owner))
+				goto dispose_child;
+
 			/* move the msk reference ownership to the subflow */
 			subflow_req->msk = NULL;
 			ctx->conn = (struct sock *)owner;
-- 
2.48.1

[PATCH 5.10.y 3/3] mptcp: sockopt: fix getting IPV6_V6ONLY

[Matthieu Baerts (NGI0)]

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 <martineau@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20250314-net-mptcp-fix-data-stream-corr-sockopt-v1-2-122dbb249db3@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
[ 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) <matttbe@kernel.org>
---
 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 level, int optname,
 	return -EOPNOTSUPP;
 }
 
+static int mptcp_put_int_option(struct mptcp_sock *msk, char __user *optval,
+				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 >= 0 && val <= 255) {
+		unsigned char ucval = (unsigned char)val;
+
+		len = 1;
+		if (put_user(len, optlen))
+			return -EFAULT;
+		if (copy_to_user(optval, &ucval, 1))
+			return -EFAULT;
+	} else {
+		len = 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 = (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 level, int optname,
 	if (ssk)
 		return tcp_getsockopt(ssk, level, optname, optval, option);
 
+	if (level == SOL_IPV6)
+		return mptcp_getsockopt_v6(msk, optname, optval, option);
 	return -EOPNOTSUPP;
 }
 
-- 
2.48.1

Re: [PATCH 5.10.y 3/3] mptcp: sockopt: fix getting IPV6_V6ONLY

[Sasha Levin]

[ Sasha's backport helper bot ]

Hi,

✅ All tests passed successfully. No issues detected.
No action required from the submitter.

The upstream commit SHA1 provided is correct: 8c39633759885b6ff85f6d96cf445560e74df5e8

Status in newer kernel trees:
6.14.y | Present (different SHA1: 233afced24eb)
6.13.y | Present (different SHA1: 41e890efe9aa)
6.12.y | Present (different SHA1: acc1f6a05ab2)
6.6.y | Present (different SHA1: 51893ff3b0f8)
6.1.y | Present (different SHA1: 0fb46064c253)
5.15.y | Not found

Note: The patch differs from the upstream commit:
---
1:  8c39633759885 < -:  ------------- mptcp: sockopt: fix getting IPV6_V6ONLY
-:  ------------- > 1:  be06d8825e39d mptcp: sockopt: fix getting IPV6_V6ONLY
---

Results of testing on various branches:

| Branch                    | Patch Apply | Build Test |
|---------------------------|-------------|------------|
| stable/linux-5.15.y       |  Success    |  Success   |

Re: [PATCH 5.10.y 1/3] mptcp: fix NULL pointer in can_accept_new_subflow

[Sasha Levin]

[ Sasha's backport helper bot ]

Hi,

✅ All tests passed successfully. No issues detected.
No action required from the submitter.

The upstream commit SHA1 provided is correct: 443041deb5ef6a1289a99ed95015ec7442f141dc

WARNING: Author mismatch between patch and upstream commit:
Backport author: "Matthieu Baerts (NGI0)"<matttbe@kernel.org>
Commit author: Gang Yan<yangang@kylinos.cn>

Status in newer kernel trees:
6.14.y | Present (different SHA1: 4bf842c5219a)
6.13.y | Present (different SHA1: 17287762277c)
6.12.y | Present (different SHA1: 56a49eaa19a3)
6.6.y | Present (different SHA1: 1385117e486d)
6.1.y | Present (different SHA1: 820fc10033ea)
5.15.y | Present (different SHA1: 01cc5110710e)

Note: The patch differs from the upstream commit:
---
1:  443041deb5ef6 ! 1:  53310442b4043 mptcp: fix NULL pointer in can_accept_new_subflow
    @@ Metadata
      ## Commit message ##
         mptcp: fix NULL pointer in can_accept_new_subflow
     
    +    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.
     
    @@ Commit message
         Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
         Link: https://patch.msgid.link/20250328-net-mptcp-misc-fixes-6-15-v1-1-34161a482a7f@kernel.org
         Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    +    [ 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) <matttbe@kernel.org>
     
      ## net/mptcp/subflow.c ##
     @@ net/mptcp/subflow.c: static bool subflow_hmac_valid(const struct request_sock *req,
    @@ net/mptcp/subflow.c: static bool subflow_hmac_valid(const struct request_sock *r
     -	if (!msk)
     -		return false;
      
    - 	subflow_generate_hmac(READ_ONCE(msk->remote_key),
    - 			      READ_ONCE(msk->local_key),
    + 	subflow_generate_hmac(msk->remote_key, msk->local_key,
    + 			      subflow_req->remote_nonce,
     @@ net/mptcp/subflow.c: static struct sock *subflow_syn_recv_sock(const struct sock *sk,
    - 
    + 			fallback = true;
      	} else if (subflow_req->mp_join) {
      		mptcp_get_options(skb, &mp_opt);
    --		if (!(mp_opt.suboptions & OPTION_MPTCP_MPJ_ACK) ||
    --		    !subflow_hmac_valid(req, &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.suboptions & OPTION_MPTCP_MPJ_ACK))
    ++		if (!mp_opt.mp_join)
      			fallback = true;
     -		}
      	}
      
      create_child:
     @@ net/mptcp/subflow.c: static struct sock *subflow_syn_recv_sock(const struct sock *sk,
    + 			if (!owner)
      				goto dispose_child;
    - 			}
      
     +			if (!subflow_hmac_valid(req, &mp_opt) ||
     +			    !mptcp_can_accept_new_subflow(subflow_req->msk)) {
     +				SUBFLOW_REQ_INC_STATS(req, MPTCP_MIB_JOINACKMAC);
    -+				subflow_add_reset_reason(skb, MPTCP_RST_EPROHIBIT);
     +				goto dispose_child;
     +			}
     +
---

Results of testing on various branches:

| Branch                    | Patch Apply | Build Test |
|---------------------------|-------------|------------|
| stable/linux-5.10.y       |  Success    |  Success   |

Re: [PATCH 5.10.y 2/3] mptcp: only inc MPJoinAckHMacFailure for HMAC failures

[Sasha Levin]

[ Sasha's backport helper bot ]

Hi,

✅ All tests passed successfully. No issues detected.
No action required from the submitter.

The upstream commit SHA1 provided is correct: 21c02e8272bc95ba0dd44943665c669029b42760

Status in newer kernel trees:
6.14.y | Present (different SHA1: f41db9f7222f)
6.13.y | Present (different SHA1: ee6cece8b2ca)
6.12.y | Present (different SHA1: 711bc4864e66)
6.6.y | Present (different SHA1: 440cc72ac34d)
6.1.y | Present (different SHA1: f92899f0301c)
5.15.y | Present (different SHA1: 738aefd9d94f)

Note: The patch differs from the upstream commit:
---
1:  21c02e8272bc9 < -:  ------------- mptcp: only inc MPJoinAckHMacFailure for HMAC failures
-:  ------------- > 1:  97a808168f008 mptcp: only inc MPJoinAckHMacFailure for HMAC failures
---

Results of testing on various branches:

| Branch                    | Patch Apply | Build Test |
|---------------------------|-------------|------------|
| stable/linux-5.15.y       |  Success    |  Success   |