From nobody Sun Dec 14 06:34:16 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 E5786215077 for ; Sun, 30 Nov 2025 03:39:45 +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=1764473987; cv=none; b=CiwEDlOv0wbFCWNvg1UMratO5U9C3r4wPf1Xa1wkd9cuwLQiGdOGZNaLf6SkQk3BGsJEw3ZDknAmQWF5cNytmDPnjv3cA1sI7Jg/+ojZw8ir6ZKbl9u7E4+Sp6ojGHhtW04kRf9STQouxQUQeASNOQtw8nZgI1K2vIUZCwxUll0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764473987; c=relaxed/simple; bh=OiwOJbJBk6q9IvkjJfVDWx3vC+KZVz4tRUwq8fXUKO8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=B/t6d+GudcE0Oxf0ShkwzwzCApusL0986mxN+GddWL0xO5ojgN4YVbHNN8/sT/p5Wg/3b7TAuX9EPK1Rb115CS4zqy1X1JAypn9ZL39GolV3Dl+px69QirL+0qMWwKZ1U2CEg0FrTqnh3WFHVnoSDyYS9/KQdUghUYTkwBp4TUo= 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 EA9AC8B2A36; Sun, 30 Nov 2025 11:23:15 +0800 (+08) From: Jiayuan Chen To: stable@vger.kernel.org, mptcp@lists.linux.dev, matthieu.baerts@tessares.net, sashal@kernel.org, gregkh@linuxfoundation.org Cc: Jiayuan Chen , Matthieu Baerts Subject: [PATCH 6.1.y v1 1/2] mptcp: disallow MPTCP subflows from sockmap Date: Sun, 30 Nov 2025 11:23:02 +0800 Message-ID: <20251130032303.324510-2-jiayuan.chen@linux.dev> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20251130032303.324510-1-jiayuan.chen@linux.dev> References: <20251130032303.324510-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() 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 ''' 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: d2f77c53342e ("mptcp: check for plain TCP sock at accept time") Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Jiayuan Chen reviewed-by/acked-by/... cannot be kept). --- net/mptcp/subflow.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c index 2159b5f9988f..c922bbb12bd8 100644 --- a/net/mptcp/subflow.c +++ b/net/mptcp/subflow.c @@ -1936,6 +1936,10 @@ void __init mptcp_subflow_init(void) =20 tcp_prot_override =3D tcp_prot; tcp_prot_override.release_cb =3D tcp_release_cb_override; +#ifdef CONFIG_BPF_SYSCALL + /* Disable sockmap processing for subflows */ + tcp_prot_override.psock_update_sk_prot =3D NULL; +#endif =20 #if IS_ENABLED(CONFIG_MPTCP_IPV6) subflow_request_sock_ipv6_ops =3D tcp_request_sock_ipv6_ops; @@ -1957,6 +1961,10 @@ void __init mptcp_subflow_init(void) =20 tcpv6_prot_override =3D tcpv6_prot; tcpv6_prot_override.release_cb =3D tcp_release_cb_override; +#ifdef CONFIG_BPF_SYSCALL + /* Disable sockmap processing for subflows */ + tcpv6_prot_override.psock_update_sk_prot =3D NULL; +#endif #endif =20 mptcp_diag_subflow_init(&subflow_ulp_ops); --=20 2.43.0 From nobody Sun Dec 14 06:34:16 2025 Received: from localhost.localdomain (unknown [147.136.157.2]) (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 E7BC622068A for ; Sun, 30 Nov 2025 03:29:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=147.136.157.2 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764473387; cv=none; b=YfvWh4x4If76nuOgeRuQTc1MHWOsNogaRTnE27F0b3hoDC9kjD1jwHgSdE9Ar/YhJLmPxG+cnhqueIwlwGUuFqrfkLPgusQjVKyE0AYa/cnNal3xkI+MNZrwKNMuW0bkdZ2WYDPMULYlSYpHqyN9LaELC+rv4SDFjPOvz2Yc5a4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764473387; c=relaxed/simple; bh=kd3WM7du0C6ez4kq47Lda47fdq2kXHgfWAlqm2mufdw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=lPGlIgnkrVgdoSVDiJ/+rEZhYFnFH8Go0ShL8Yf6i76JG5nzNogXRzgZDsmPExzVzjinaEjG8oCt7rJoaj+J6ihgHoFydD8VvvIT00XSPQdJ0sYZH8rOF0fo6q6nm0rHllHdWaj0eXXsz+MqsUQbTzNra5QLnhdIxMooKleGF3k= 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.2 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 9C7FE8B2A3B; Sun, 30 Nov 2025 11:23:16 +0800 (+08) From: Jiayuan Chen To: stable@vger.kernel.org, mptcp@lists.linux.dev, matthieu.baerts@tessares.net, sashal@kernel.org, gregkh@linuxfoundation.org Cc: Jiayuan Chen , Jakub Sitnicki , Matthieu Baerts Subject: [PATCH 6.1.y v1 2/2] net,mptcp: fix proto fallback detection with BPF Date: Sun, 30 Nov 2025 11:23:03 +0800 Message-ID: <20251130032303.324510-3-jiayuan.chen@linux.dev> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20251130032303.324510-1-jiayuan.chen@linux.dev> References: <20251130032303.324510-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 PANIC from occurring: result from ./scripts/decode_stacktrace.sh: Reviewed-by: Jakub Sitnicki Reviewed-by: Matthieu Baerts (NGI0) reviewed-by/acked-by/... cannot be kept). ------------[ cut here ]------------ BUG: kernel NULL pointer dereference, address: 00000000000004bb PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI CPU: 0 PID: 400 Comm: test_progs Not tainted 6.1.0+ #16 RIP: 0010:mptcp_stream_accept (./include/linux/list.h:88 net/mptcp/protocol= .c:3719) RSP: 0018:ffffc90000ef3cf0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff8880089dcc58 RDX: 0000000000000003 RSI: 0000002c000000b0 RDI: 0000000000000000 RBP: ffffc90000ef3d38 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8880089dc600 R13: ffff88800b859e00 R14: ffff88800638c680 R15: 0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000004bb CR3: 000000000b8e8006 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? apparmor_socket_accept (security/apparmor/lsm.c:966) do_accept (net/socket.c:1856) __sys_accept4 (net/socket.c:1897 net/socket.c:1927) __x64_sys_accept (net/socket.c:1941) do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80) Fixes: d2f77c53342e ("mptcp: check for plain TCP sock at accept time") Reviewed-by: Jakub Sitnicki Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Jiayuan Chen --- net/mptcp/protocol.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index 1dbc62537259..13e3510e6c8f 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -79,8 +79,9 @@ static u64 mptcp_wnd_end(const struct mptcp_sock *msk) static bool mptcp_is_tcpsk(struct sock *sk) { struct socket *sock =3D sk->sk_socket; + unsigned short family =3D READ_ONCE(sk->sk_family); =20 - if (unlikely(sk->sk_prot =3D=3D &tcp_prot)) { + if (unlikely(family =3D=3D 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. @@ -91,7 +92,7 @@ static bool mptcp_is_tcpsk(struct sock *sk) sock->ops =3D &inet_stream_ops; return true; #if IS_ENABLED(CONFIG_MPTCP_IPV6) - } else if (unlikely(sk->sk_prot =3D=3D &tcpv6_prot)) { + } else if (unlikely(family =3D=3D AF_INET6)) { sock->ops =3D &inet6_stream_ops; return true; #endif --=20 2.43.0