* Re: FAILED: patch "[PATCH] mptcp: Disallow MPTCP subflows from sockmap" failed to apply to 5.10-stable tree
[not found] <2025112455-daughter-unsealed-699a@gregkh>
@ 2025-12-01 12:17 ` Matthieu Baerts
0 siblings, 0 replies; only message in thread
From: Matthieu Baerts @ 2025-12-01 12:17 UTC (permalink / raw)
To: gregkh, jiayuan.chen, martin.lau; +Cc: MPTCP Linux, stable
[-- Attachment #1: Type: text/plain, Size: 4602 bytes --]
Hello,
On 24/11/2025 14:21, gregkh@linuxfoundation.org wrote:
>
> The patch below does not apply to the 5.10-stable tree.
> If someone wants it applied there, or to any other stable or longterm
> tree, then please email the backport, including the original git commit
> id to <stable@vger.kernel.org>.
Thank you for the notification!
> To reproduce the conflict and resubmit, you may use the following commands:
>
> git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y
> git checkout FETCH_HEAD
> git cherry-pick -x fbade4bd08ba52cbc74a71c4e86e736f059f99f7
> # <resolve conflicts, build, test, etc.>
> git commit -s
> git send-email --to '<stable@vger.kernel.org>' --in-reply-to '2025112455-daughter-unsealed-699a@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^..
>
> Possible dependencies:
>
>
>
> thanks,
>
> greg k-h
>
> ------------------ original commit in Linus's tree ------------------
>
> From fbade4bd08ba52cbc74a71c4e86e736f059f99f7 Mon Sep 17 00:00:00 2001
> From: Jiayuan Chen <jiayuan.chen@linux.dev>
> Date: Tue, 11 Nov 2025 14:02:50 +0800
> Subject: [PATCH] mptcp: Disallow MPTCP subflows from sockmap
>
> The sockmap feature allows bpf syscall from userspace, or based on bpf
> sockops, replacing the sk_prot of sockets during protocol stack processing
> with sockmap's custom read/write interfaces.
> '''
> tcp_rcv_state_process()
> subflow_syn_recv_sock()
> tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB)
> bpf_skops_established <== sockops
> bpf_sock_map_update(sk) <== call bpf helper
> tcp_bpf_update_proto() <== update sk_prot
> '''
> Consider two scenarios:
>
> 1. When the server has MPTCP enabled and the client also requests MPTCP,
> the sk passed to the BPF program is a subflow sk. Since subflows only
> handle partial data, replacing their sk_prot is meaningless and will
> cause traffic disruption.
>
> 2. When the server has MPTCP enabled but the client sends a TCP SYN
> without MPTCP, subflow_syn_recv_sock() performs a fallback on the
> subflow, replacing the subflow sk's sk_prot with the native sk_prot.
> '''
> subflow_ulp_fallback()
> subflow_drop_ctx()
> mptcp_subflow_ops_undo_override()
> '''
> Subsequently, accept::mptcp_stream_accept::mptcp_fallback_tcp_ops()
> converts the subflow to plain TCP.
>
> For the first case, we should prevent it from being combined with sockmap
> by setting sk_prot->psock_update_sk_prot to NULL, which will be blocked by
> sockmap's own flow.
>
> For the second case, since subflow_syn_recv_sock() has already restored
> sk_prot to native tcp_prot/tcpv6_prot, no further action is needed.
>
> Fixes: cec37a6e41aa ("mptcp: Handle MP_CAPABLE options for outgoing connections")
> Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
> Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
> Cc: <stable@vger.kernel.org>
> Link: https://patch.msgid.link/20251111060307.194196-2-jiayuan.chen@linux.dev
>
> diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c
> index e8325890a322..af707ce0f624 100644
> --- a/net/mptcp/subflow.c
> +++ b/net/mptcp/subflow.c
> @@ -2144,6 +2144,10 @@ void __init mptcp_subflow_init(void)
> tcp_prot_override = tcp_prot;
> tcp_prot_override.release_cb = tcp_release_cb_override;
> tcp_prot_override.diag_destroy = tcp_abort_override;
> +#ifdef CONFIG_BPF_SYSCALL
> + /* Disable sockmap processing for subflows */
> + tcp_prot_override.psock_update_sk_prot = NULL;
> +#endif
>
> #if IS_ENABLED(CONFIG_MPTCP_IPV6)
> /* In struct mptcp_subflow_request_sock, we assume the TCP request sock
> @@ -2180,6 +2184,10 @@ void __init mptcp_subflow_init(void)
> tcpv6_prot_override = tcpv6_prot;
> tcpv6_prot_override.release_cb = tcp_release_cb_override;
> tcpv6_prot_override.diag_destroy = tcp_abort_override;
> +#ifdef CONFIG_BPF_SYSCALL
> + /* Disable sockmap processing for subflows */
> + tcpv6_prot_override.psock_update_sk_prot = NULL;
> +#endif
> #endif
>
> mptcp_diag_subflow_init(&subflow_ulp_ops);
>
FYI, the patch cannot be applied on v5.10 because
sk_prot->psock_update_sk_prot is not available, see commit 8a59f9d1e3d4
("sock: Introduce sk->sk_prot->psock_update_sk_prot()").
I have attached an **RFC** patch for anyone who would be ready to test
it, but please don't apply it before these tests: I don't want to break
things on TCP sockmap side. (That's why I'm attaching the patch and not
sending it the proper way.)
Cheers,
Matt
--
Sponsored by the NGI0 Core fund.
[-- Attachment #2: 0001-mptcp-Disallow-MPTCP-subflows-from-sockmap.patch --]
[-- Type: text/x-patch, Size: 3500 bytes --]
From 436744f1d0ce2257d9fea34a40d2adb18dcb330b Mon Sep 17 00:00:00 2001
From: Jiayuan Chen <jiayuan.chen@linux.dev>
Date: Tue, 11 Nov 2025 14:02:50 +0800
Subject: [PATCH RFC] mptcp: Disallow MPTCP subflows from sockmap
commit fbade4bd08ba52cbc74a71c4e86e736f059f99f7
The sockmap feature allows bpf syscall from userspace, or based on bpf
sockops, replacing the sk_prot of sockets during protocol stack processing
with sockmap's custom read/write interfaces.
'''
tcp_rcv_state_process()
subflow_syn_recv_sock()
tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB)
bpf_skops_established <== sockops
bpf_sock_map_update(sk) <== call bpf helper
tcp_bpf_update_proto() <== update sk_prot
'''
Consider two scenarios:
1. When the server has MPTCP enabled and the client also requests MPTCP,
the sk passed to the BPF program is a subflow sk. Since subflows only
handle partial data, replacing their sk_prot is meaningless and will
cause traffic disruption.
2. When the server has MPTCP enabled but the client sends a TCP SYN
without MPTCP, subflow_syn_recv_sock() performs a fallback on the
subflow, replacing the subflow sk's sk_prot with the native sk_prot.
'''
subflow_ulp_fallback()
subflow_drop_ctx()
mptcp_subflow_ops_undo_override()
'''
Subsequently, accept::mptcp_stream_accept::mptcp_fallback_tcp_ops()
converts the subflow to plain TCP.
For the first case, we should prevent it from being combined with sockmap
by setting sk_prot->psock_update_sk_prot to NULL, which will be blocked by
sockmap's own flow.
For the second case, since subflow_syn_recv_sock() has already restored
sk_prot to native tcp_prot/tcpv6_prot, no further action is needed.
Fixes: cec37a6e41aa ("mptcp: Handle MP_CAPABLE options for outgoing connections")
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Cc: <stable@vger.kernel.org>
Link: https://patch.msgid.link/20251111060307.194196-2-jiayuan.chen@linux.dev
[ In this version, sk_prot->psock_update_sk_prot is not available, see
commit 8a59f9d1e3d4 ("sock: Introduce sk->sk_prot->psock_update_sk_prot()").
Instead of checking the family, restrict only to the TCP protocol. ]
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
net/ipv4/tcp_bpf.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/tcp_bpf.c b/net/ipv4/tcp_bpf.c
index bcd5fc484f77..47133393d69c 100644
--- a/net/ipv4/tcp_bpf.c
+++ b/net/ipv4/tcp_bpf.c
@@ -10,6 +10,7 @@
#include <net/inet_common.h>
#include <net/tls.h>
+#include <net/transp_v6.h>
int __tcp_bpf_recvmsg(struct sock *sk, struct sk_psock *psock,
struct msghdr *msg, int len, int flags)
@@ -627,14 +628,16 @@ struct proto *tcp_bpf_get_proto(struct sock *sk, struct sk_psock *psock)
int family = sk->sk_family == AF_INET6 ? TCP_BPF_IPV6 : TCP_BPF_IPV4;
int config = psock->progs.msg_parser ? TCP_BPF_TX : TCP_BPF_BASE;
- if (sk->sk_family == AF_INET6) {
+ if (sk->sk_prot == &tcpv6_prot) {
if (tcp_bpf_assert_proto_ops(psock->sk_proto))
return ERR_PTR(-EINVAL);
tcp_bpf_check_v6_needs_rebuild(psock->sk_proto);
+ } else if (sk->sk_prot == &tcp_prot) {
+ return &tcp_bpf_prots[family][config];
}
- return &tcp_bpf_prots[family][config];
+ return ERR_PTR(-EINVAL);
}
/* If a child got cloned from a listening socket that had tcp_bpf
--
2.51.0
^ permalink raw reply related [flat|nested] only message in thread