netdev - Re: [PATCH net] mptcp: prevent BPF accessing lowat from a subflow socket.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2a68e09b-936c-447d-bfe8-bd043c94306c@kernel.org>
Date: Fri, 29 Mar 2024 12:53:06 -0700 (PDT)
From: Mat Martineau <martineau@...nel.org>
To: Paolo Abeni <pabeni@...hat.com>
cc: netdev@...r.kernel.org, Matthieu Baerts <matttbe@...nel.org>, 
    Geliang Tang <geliang@...nel.org>, "David S. Miller" <davem@...emloft.net>, 
    Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, 
    mptcp@...ts.linux.dev, bpf@...r.kernel.org
Subject: Re: [PATCH net] mptcp: prevent BPF accessing lowat from a subflow
 socket.

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@...nel.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@...il.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@...hat.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
>
>