From nobody Tue Nov 11 13:06:24 2025 Received: from localhost.localdomain (unknown [147.136.157.3]) (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 257E4285C99 for ; Tue, 11 Nov 2025 06:03:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=147.136.157.3 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762841001; cv=none; b=HQyg5Ao5QzOqBMQwp5WrEf7ZJX9DzHV4cgz+GySV2JaM0Dmt+3Vef8/CGY2oC9O3W/7bbTVtPGso+KmlbfOZj891rVo7r5f6lA0HhLh3WKl3hCwzkTiwUKFO6ms+Vboavc3nWtK9v87JG+iCyvmLnlnrfEjV3P74tuI9vzLCRI8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762841001; c=relaxed/simple; bh=kGRmQam432BJbD6BROFIQPV8PElNINTvJRdMDm3Xoj0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=npyO33YRCyAhy2zYtHoYpKRoUd53+t0EoXDvfhf7R0Omm2BTMFsG7PK1QVFtWyIlRy6JlYDxTMZeKteLu03auBGvhkWdwdVgp36kRlliQNP54rJSik/DTtHwAG7rnyeEsSZHXiBBqKBrSt+RcIG7ef0VfJ4Ao6GUu+sCl8WY0oM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.dev; spf=none smtp.mailfrom=localhost.localdomain; arc=none smtp.client-ip=147.136.157.3 Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=localhost.localdomain Received: by localhost.localdomain (Postfix, from userid 1007) id 64F408B2A0D; Tue, 11 Nov 2025 14:03:17 +0800 (+08) From: Jiayuan Chen To: mptcp@lists.linux.dev Cc: Jiayuan Chen , stable@vger.kernel.org, Jakub Sitnicki , Matthieu Baerts , Mat Martineau , Geliang Tang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Eduard Zingerman , Song Liu , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Hao Luo , Jiri Olsa , Shuah Khan , Peter Krystad , Florian Westphal , Christoph Paasch , linux-kernel@vger.kernel.org, netdev@vger.kernel.org, bpf@vger.kernel.org, linux-kselftest@vger.kernel.org Subject: [PATCH net v5 2/3] net,mptcp: fix proto fallback detection with BPF Date: Tue, 11 Nov 2025 14:02:51 +0800 Message-ID: <20251111060307.194196-3-jiayuan.chen@linux.dev> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20251111060307.194196-1-jiayuan.chen@linux.dev> References: <20251111060307.194196-1-jiayuan.chen@linux.dev> Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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 <=3D=3D sockops bpf_sock_map_update(sk) <=3D=3D call bpf helper tcp_bpf_update_proto() <=3D=3D 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: Reviewed-by: Jakub Sitnicki Reviewed-by: Matthieu Baerts (NGI0) ------------[ 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: 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:9= 4) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f87ac92b83d ---[ end trace 0000000000000000 ]--- Fixes: cec37a6e41aa ("mptcp: Handle MP_CAPABLE options for outgoing connect= ions") Cc: Signed-off-by: Jiayuan Chen Reviewed-by: Jakub Sitnicki Reviewed-by: Matthieu Baerts (NGI0) --- net/mptcp/protocol.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index 2d6b8de35c44..90b4aeca2596 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -61,11 +61,13 @@ static u64 mptcp_wnd_end(const struct mptcp_sock *msk) =20 static const struct proto_ops *mptcp_fallback_tcp_ops(const struct sock *s= k) { + unsigned short family =3D READ_ONCE(sk->sk_family); + #if IS_ENABLED(CONFIG_MPTCP_IPV6) - if (sk->sk_prot =3D=3D &tcpv6_prot) + if (family =3D=3D AF_INET6) return &inet6_stream_ops; #endif - WARN_ON_ONCE(sk->sk_prot !=3D &tcp_prot); + WARN_ON_ONCE(family !=3D AF_INET); return &inet_stream_ops; } =20 --=20 2.43.0