Alexei reported the following splat:
WARNING: CPU: 32 PID: 3276 at net/mptcp/subflow.c:1430 subflow_data_ready+0x147/0x1c0
Modules linked in: dummy bpf_testmod(O) [last unloaded: bpf_test_no_cfi(O)]
CPU: 32 PID: 3276 Comm: test_progs Tainted: GO 6.8.0-12873-g2c43c33bfd23
Call Trace:
<TASK>
mptcp_set_rcvlowat+0x79/0x1d0
sk_setsockopt+0x6c0/0x1540
__bpf_setsockopt+0x6f/0x90
bpf_sock_ops_setsockopt+0x3c/0x90
bpf_prog_509ce5db2c7f9981_bpf_test_sockopt_int+0xb4/0x11b
bpf_prog_dce07e362d941d2b_bpf_test_socket_sockopt+0x12b/0x132
bpf_prog_348c9b5faaf10092_skops_sockopt+0x954/0xe86
__cgroup_bpf_run_filter_sock_ops+0xbc/0x250
tcp_connect+0x879/0x1160
tcp_v6_connect+0x50c/0x870
mptcp_connect+0x129/0x280
__inet_stream_connect+0xce/0x370
inet_stream_connect+0x36/0x50
bpf_trampoline_6442491565+0x49/0xef
inet_stream_connect+0x5/0x50
__sys_connect+0x63/0x90
__x64_sys_connect+0x14/0x20
The root cause of the issue is that bpf allows accessing mptcp-level
proto_ops from a tcp subflow scope.
Fix the issue detecting the problematic call and preventing any action.
Reported-by: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/482
Fixes: 5684ab1a0eff ("mptcp: give rcvlowat some love")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
---
net/mptcp/sockopt.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/net/mptcp/sockopt.c b/net/mptcp/sockopt.c
index dcd1c76d2a3b..73fdf423de44 100644
--- a/net/mptcp/sockopt.c
+++ b/net/mptcp/sockopt.c
@@ -1493,6 +1493,10 @@ int mptcp_set_rcvlowat(struct sock *sk, int val)
struct mptcp_subflow_context *subflow;
int space, cap;
+ /* bpf can land here with a wrong sk type */
+ if (sk->sk_protocol == IPPROTO_TCP)
+ return -EINVAL;
+
if (sk->sk_userlocks & SOCK_RCVBUF_LOCK)
cap = sk->sk_rcvbuf >> 1;
else
--
2.43.2
Hi Paolo, On 29/03/2024 19:50, Paolo Abeni wrote: > Alexei reported the following splat: > > WARNING: CPU: 32 PID: 3276 at net/mptcp/subflow.c:1430 subflow_data_ready+0x147/0x1c0 > Modules linked in: dummy bpf_testmod(O) [last unloaded: bpf_test_no_cfi(O)] > CPU: 32 PID: 3276 Comm: test_progs Tainted: GO 6.8.0-12873-g2c43c33bfd23 > Call Trace: > <TASK> > mptcp_set_rcvlowat+0x79/0x1d0 > sk_setsockopt+0x6c0/0x1540 > __bpf_setsockopt+0x6f/0x90 > bpf_sock_ops_setsockopt+0x3c/0x90 > bpf_prog_509ce5db2c7f9981_bpf_test_sockopt_int+0xb4/0x11b > bpf_prog_dce07e362d941d2b_bpf_test_socket_sockopt+0x12b/0x132 > bpf_prog_348c9b5faaf10092_skops_sockopt+0x954/0xe86 > __cgroup_bpf_run_filter_sock_ops+0xbc/0x250 > tcp_connect+0x879/0x1160 > tcp_v6_connect+0x50c/0x870 > mptcp_connect+0x129/0x280 > __inet_stream_connect+0xce/0x370 > inet_stream_connect+0x36/0x50 > bpf_trampoline_6442491565+0x49/0xef > inet_stream_connect+0x5/0x50 > __sys_connect+0x63/0x90 > __x64_sys_connect+0x14/0x20 > > The root cause of the issue is that bpf allows accessing mptcp-level > proto_ops from a tcp subflow scope. > > Fix the issue detecting the problematic call and preventing any action. Thank you for having looked at that! The patch looks good to me as well: Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> FYI, the patch was also OK for our CI, but we don't run all BPF tests. Cheers, Matt -- Sponsored by the NGI0 Core fund.
On Fri, 29 Mar 2024, Paolo Abeni wrote: > Alexei reported the following splat: > > WARNING: CPU: 32 PID: 3276 at net/mptcp/subflow.c:1430 subflow_data_ready+0x147/0x1c0 > Modules linked in: dummy bpf_testmod(O) [last unloaded: bpf_test_no_cfi(O)] > CPU: 32 PID: 3276 Comm: test_progs Tainted: GO 6.8.0-12873-g2c43c33bfd23 > Call Trace: > <TASK> > mptcp_set_rcvlowat+0x79/0x1d0 > sk_setsockopt+0x6c0/0x1540 > __bpf_setsockopt+0x6f/0x90 > bpf_sock_ops_setsockopt+0x3c/0x90 > bpf_prog_509ce5db2c7f9981_bpf_test_sockopt_int+0xb4/0x11b > bpf_prog_dce07e362d941d2b_bpf_test_socket_sockopt+0x12b/0x132 > bpf_prog_348c9b5faaf10092_skops_sockopt+0x954/0xe86 > __cgroup_bpf_run_filter_sock_ops+0xbc/0x250 > tcp_connect+0x879/0x1160 > tcp_v6_connect+0x50c/0x870 > mptcp_connect+0x129/0x280 > __inet_stream_connect+0xce/0x370 > inet_stream_connect+0x36/0x50 > bpf_trampoline_6442491565+0x49/0xef > inet_stream_connect+0x5/0x50 > __sys_connect+0x63/0x90 > __x64_sys_connect+0x14/0x20 > Thanks Paolo, change LGTM: Reviewed-by: Mat Martineau <martineau@kernel.org> > The root cause of the issue is that bpf allows accessing mptcp-level > proto_ops from a tcp subflow scope. What should we do about this root cause going forward? Does this fall on the MPTCP subsystem to add special checks in places where proto_ops are accessed via sk_socket? Or is there a more generic way to catch this? - Mat > > Fix the issue detecting the problematic call and preventing any action. > > Reported-by: Alexei Starovoitov <alexei.starovoitov@gmail.com> > Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/482 > Fixes: 5684ab1a0eff ("mptcp: give rcvlowat some love") > Signed-off-by: Paolo Abeni <pabeni@redhat.com> > --- > net/mptcp/sockopt.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/net/mptcp/sockopt.c b/net/mptcp/sockopt.c > index dcd1c76d2a3b..73fdf423de44 100644 > --- a/net/mptcp/sockopt.c > +++ b/net/mptcp/sockopt.c > @@ -1493,6 +1493,10 @@ int mptcp_set_rcvlowat(struct sock *sk, int val) > struct mptcp_subflow_context *subflow; > int space, cap; > > + /* bpf can land here with a wrong sk type */ > + if (sk->sk_protocol == IPPROTO_TCP) > + return -EINVAL; > + > if (sk->sk_userlocks & SOCK_RCVBUF_LOCK) > cap = sk->sk_rcvbuf >> 1; > else > -- > 2.43.2 > >
© 2016 - 2024 Red Hat, Inc.