December 1, 2025 at 19:27, "Matthieu Baerts (NGI0)" <matttbe@kernel.org mailto:matttbe@kernel.org?to=%22Matthieu%20Baerts%20(NGI0)%22%20%3Cmatttbe%40kernel.org%3E > wrote:
From: Jiayuan Chen jiayuan.chen@linux.dev
commit c77b3b79a92e3345aa1ee296180d1af4e7031f8f upstream.
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() syn_recv_sock()/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 '''
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_syn_recv_sock() subflow_ulp_fallback() subflow_drop_ctx() mptcp_subflow_ops_undo_override() '''
Then, this subflow can be normally used by sockmap, which replaces the native sk_prot with sockmap's custom sk_prot. The issue occurs when the user executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops(). Here, it uses sk->sk_prot to compare with the native sk_prot, but this is incorrect when sockmap is used, as we may incorrectly set sk->sk_socket->ops.
This fix uses the more generic sk_family for the comparison instead.
Additionally, this also prevents a WARNING from occurring:
result from ./scripts/decode_stacktrace.sh: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \ (net/mptcp/protocol.c:4005) Modules linked in: ...
PKRU: 55555554 Call Trace:
<TASK> do_accept (net/socket.c:1989) __sys_accept4 (net/socket.c:2028 net/socket.c:2057) __x64_sys_accept (net/socket.c:2067) x64_sys_call (arch/x86/entry/syscall_64.c:41) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f87ac92b83d
---[ end trace 0000000000000000 ]---
Fixes: 0b4f33def7bb ("mptcp: fix tcp fallback crash") Signed-off-by: Jiayuan Chen jiayuan.chen@linux.dev Signed-off-by: Martin KaFai Lau martin.lau@kernel.org Reviewed-by: Jakub Sitnicki jakub@cloudflare.com Reviewed-by: Matthieu Baerts (NGI0) matttbe@kernel.org Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251111060307.194196-3-jiayuan.chen@linux.dev [ Conflicts in protocol.c, because commit 8e2b8a9fa512 ("mptcp: don't overwrite sock_ops in mptcp_is_tcpsk()") is not in this version. It changes the logic on how and where the sock_ops is overridden in case of passive fallback. To fix this, mptcp_is_tcpsk() is modified to use the family, but first, a check of the protocol is required to continue returning 'false' in case of MPTCP socket. ] Signed-off-by: Matthieu Baerts (NGI0) matttbe@kernel.org
net/mptcp/protocol.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index f89de0f7b3e5..98fd4ffe6f11 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -77,8 +77,13 @@ static u64 mptcp_wnd_end(const struct mptcp_sock *msk) static bool mptcp_is_tcpsk(struct sock *sk) { struct socket *sock = sk->sk_socket;
- unsigned short family;
- if (unlikely(sk->sk_prot == &tcp_prot)) {
- if (likely(sk->sk_protocol == IPPROTO_MPTCP))
- return false;
- family = READ_ONCE(sk->sk_family);
- if (unlikely(family == AF_INET)) {
/* we are being invoked after mptcp_accept() has
- accepted a non-mp-capable flow: sk is a tcp_sk,
- not an mptcp one.
@@ -89,7 +94,7 @@ static bool mptcp_is_tcpsk(struct sock *sk) sock->ops = &inet_stream_ops; return true; #if IS_ENABLED(CONFIG_MPTCP_IPV6)
- } else if (unlikely(sk->sk_prot == &tcpv6_prot)) {
- } else if (unlikely(family == AF_INET6)) {
sock->ops = &inet6_stream_ops; return true;
#endif
2.51.0
Thanks — I happened to have a 5.15 environment, and I’ve successfully tested the patch there. I believe 5.10 should behave the same way.
Before applying the patch, the following panic occurred. After applying it, the panic disappeared. I think this is sufficient to confirm the fix works for both 5.15 and 5.10.
BUG: unable to handle page fault for address: 0000000dd85a1764 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI CPU: 0 PID: 373 Comm: test_progs Not tainted 5.15.189+ #11 RIP: 0010:mptcp_stream_accept+0x118/0x3c0 RSP: 0018:ffffc90000907ad8 EFLAGS: 00010246 RAX: 0000000dd85a129c RBX: ffff88800c52c000 RCX: 0000000000000000 RDX: 00030d4000030d40 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc90000907b30 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8880050ada00 R13: ffff888005099d40 R14: ffff888007368670 R15: ffff888007368000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000dd85a1764 CR3: 0000000006e20004 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? apparmor_socket_accept+0x1e/0x30 do_accept+0x12a/0x1b0 __sys_accept4_file+0x55/0xb0 __sys_accept4+0x62/0xc0 __x64_sys_accept+0x1b/0x30 x64_sys_call+0x1a57/0x2190