* [PATCH 5.10.y 1/3] mptcp: fix NULL pointer in can_accept_new_subflow
2025-04-18 16:45 [PATCH 5.10.y 0/3] mptcp: fix recent failed backports Matthieu Baerts (NGI0)
@ 2025-04-18 16:45 ` Matthieu Baerts (NGI0)
2025-04-19 11:50 ` Sasha Levin
2025-04-18 16:45 ` [PATCH 5.10.y 2/3] mptcp: only inc MPJoinAckHMacFailure for HMAC failures Matthieu Baerts (NGI0)
2025-04-18 16:46 ` [PATCH 5.10.y 3/3] mptcp: sockopt: fix getting IPV6_V6ONLY Matthieu Baerts (NGI0)
2 siblings, 1 reply; 7+ messages in thread
From: Matthieu Baerts (NGI0) @ 2025-04-18 16:45 UTC (permalink / raw)
To: mptcp, stable, gregkh
Cc: Gang Yan, sashal, Paolo Abeni, Matthieu Baerts (NGI0),
Jakub Kicinski
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
^ permalink raw reply related [flat|nested] 7+ messages in thread* [PATCH 5.10.y 2/3] mptcp: only inc MPJoinAckHMacFailure for HMAC failures
2025-04-18 16:45 [PATCH 5.10.y 0/3] mptcp: fix recent failed backports Matthieu Baerts (NGI0)
2025-04-18 16:45 ` [PATCH 5.10.y 1/3] mptcp: fix NULL pointer in can_accept_new_subflow Matthieu Baerts (NGI0)
@ 2025-04-18 16:45 ` Matthieu Baerts (NGI0)
2025-04-19 11:50 ` Sasha Levin
2025-04-18 16:46 ` [PATCH 5.10.y 3/3] mptcp: sockopt: fix getting IPV6_V6ONLY Matthieu Baerts (NGI0)
2 siblings, 1 reply; 7+ messages in thread
From: Matthieu Baerts (NGI0) @ 2025-04-18 16:45 UTC (permalink / raw)
To: mptcp, stable, gregkh
Cc: Matthieu Baerts (NGI0), sashal, Geliang Tang, Simon Horman,
Jakub Kicinski
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
^ permalink raw reply related [flat|nested] 7+ messages in thread* [PATCH 5.10.y 3/3] mptcp: sockopt: fix getting IPV6_V6ONLY
2025-04-18 16:45 [PATCH 5.10.y 0/3] mptcp: fix recent failed backports Matthieu Baerts (NGI0)
2025-04-18 16:45 ` [PATCH 5.10.y 1/3] mptcp: fix NULL pointer in can_accept_new_subflow Matthieu Baerts (NGI0)
2025-04-18 16:45 ` [PATCH 5.10.y 2/3] mptcp: only inc MPJoinAckHMacFailure for HMAC failures Matthieu Baerts (NGI0)
@ 2025-04-18 16:46 ` Matthieu Baerts (NGI0)
2025-04-19 11:46 ` Sasha Levin
2 siblings, 1 reply; 7+ messages in thread
From: Matthieu Baerts (NGI0) @ 2025-04-18 16:46 UTC (permalink / raw)
To: mptcp, stable, gregkh
Cc: Matthieu Baerts (NGI0), sashal, Mat Martineau, Simon Horman,
Paolo Abeni
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
^ permalink raw reply related [flat|nested] 7+ messages in thread