| Message ID | d8cb7d8476d66cb0812a6e29cd1e626869d9d53e.1711738080.git.pabeni@redhat.com (mailing list archive) |
|---|---|
| State | Mainlined, archived |
| Commit | 3420bf1f1aa7b74eaee47a1e695cd48fbae6902c |
| Delegated to: | Matthieu Baerts |
| Headers | show |
| Series | [net] mptcp: prevent BPF accessing lowat from a subflow socket. | expand |
| Context | Check | Description |
|---|---|---|
| matttbe/build | success | Build and static analysis OK |
| matttbe/checkpatch | success | total: 0 errors, 0 warnings, 0 checks, 10 lines checked |
| matttbe/shellcheck | success | MPTCP selftests files have not been modified |
| matttbe/KVM_Validation__normal | success | Success! ✅ |
| matttbe/KVM_Validation__debug | success | Success! ✅ |
| matttbe/KVM_Validation__btf__only_bpftest_all_ | success | Success! ✅ |
Hi Paolo,
Thank you for your modifications, that's great!
Our CI did some validations and here is its report:
- KVM Validation: normal: Success! ✅
- KVM Validation: debug: Success! ✅
- KVM Validation: btf (only bpftest_all): Success! ✅
- Task: https://github.com/multipath-tcp/mptcp_net-next/actions/runs/8484623071
Initiator: Patchew Applier
Commits: https://github.com/multipath-tcp/mptcp_net-next/commits/3e7afe954a2d
Patchwork: https://patchwork.kernel.org/project/mptcp/list/?series=839872
If there are some issues, you can reproduce them using the same environment as
the one used by the CI thanks to a docker image, e.g.:
$ cd [kernel source code]
$ docker run -v "${PWD}:${PWD}:rw" -w "${PWD}" --privileged --rm -it \
--pull always mptcp/mptcp-upstream-virtme-docker:latest \
auto-normal
For more details:
https://github.com/multipath-tcp/mptcp-upstream-virtme-docker
Please note that despite all the efforts that have been already done to have a
stable tests suite when executed on a public CI like here, it is possible some
reported issues are not due to your modifications. Still, do not hesitate to
help us improve that ;-)
Cheers,
MPTCP GH Action bot
Bot operated by Matthieu Baerts (NGI0 Core)
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 > >
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
Hello: This patch was applied to netdev/net.git (main) by Jakub Kicinski <kuba@kernel.org>: On Fri, 29 Mar 2024 19:50:36 +0100 you 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 > > [...] Here is the summary with links: - [net] mptcp: prevent BPF accessing lowat from a subflow socket. https://git.kernel.org/netdev/net/c/fcf4692fa39e You are awesome, thank you!
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
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(+)