All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Lau <kafai@fb.com>
To: Lorenz Bauer <lmb@cloudflare.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	"David S. Miller" <davem@davemloft.net>,
	Joe Stringer <joe@isovalent.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"bpf@vger.kernel.org" <bpf@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"kernel-team@cloudflare.com" <kernel-team@cloudflare.com>,
	"edumazet@google.com" <edumazet@google.com>
Subject: Re: [PATCH bpf 1/1] net: bpf: don't leak time wait and request sockets
Date: Thu, 9 Jan 2020 18:23:43 +0000	[thread overview]
Message-ID: <20200109182335.um72tp73krvvubnl@kafai-mbp.dhcp.thefacebook.com> (raw)
In-Reply-To: <20200109115749.12283-2-lmb@cloudflare.com>

On Thu, Jan 09, 2020 at 11:57:48AM +0000, Lorenz Bauer wrote:
> It's possible to leak time wait and request sockets via the following
> BPF pseudo code:
>  
>   sk = bpf_skc_lookup_tcp(...)
>   if (sk)
>     bpf_sk_release(sk)
> 
> If sk->sk_state is TCP_NEW_SYN_RECV or TCP_TIME_WAIT the refcount taken
> by bpf_skc_lookup_tcp is not undone by bpf_sk_release. This is because
> sk_flags is re-used for other data in both kinds of sockets. The check
Thanks for the report.

> 
>   !sock_flag(sk, SOCK_RCU_FREE)
> 
> therefore returns a bogus result.
> 
> Introduce a helper to account for this complication, and call it from
> the necessary places.
> 
> Fixes: edbf8c01de5a ("bpf: add skc_lookup_tcp helper")
> Fixes: f7355a6c0497 ("bpf: Check sk_fullsock() before returning from bpf_sk_lookup()")
> Signed-off-by: Lorenz Bauer <lmb@cloudflare.com>
> ---
>  net/core/filter.c | 17 +++++++++++------
>  1 file changed, 11 insertions(+), 6 deletions(-)
> 
> diff --git a/net/core/filter.c b/net/core/filter.c
> index 42fd17c48c5f..d98dc4526d82 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -5266,6 +5266,14 @@ __bpf_skc_lookup(struct sk_buff *skb, struct bpf_sock_tuple *tuple, u32 len,
>  	return sk;
>  }
>  
> +static void __bpf_sk_release(struct sock *sk)
> +{
> +	/* time wait and request socks don't have sk_flags. */
> +	if (sk->sk_state == TCP_TIME_WAIT || sk->sk_state == TCP_NEW_SYN_RECV ||
> +	    !sock_flag(sk, SOCK_RCU_FREE))
Would this work too?
	if (!sk_fullsock(sk) || !sock_flag(sk, SOCK_RCU_FREE))

> +		sock_gen_put(sk);
> +}
> +
>  static struct sock *
>  __bpf_sk_lookup(struct sk_buff *skb, struct bpf_sock_tuple *tuple, u32 len,
>  		struct net *caller_net, u32 ifindex, u8 proto, u64 netns_id,
> @@ -5277,8 +5285,7 @@ __bpf_sk_lookup(struct sk_buff *skb, struct bpf_sock_tuple *tuple, u32 len,
>  	if (sk) {
>  		sk = sk_to_full_sk(sk);
>  		if (!sk_fullsock(sk)) {
> -			if (!sock_flag(sk, SOCK_RCU_FREE))
> -				sock_gen_put(sk);
> +			__bpf_sk_release(sk);
>  			return NULL;
>  		}
>  	}
> @@ -5315,8 +5322,7 @@ bpf_sk_lookup(struct sk_buff *skb, struct bpf_sock_tuple *tuple, u32 len,
>  	if (sk) {
>  		sk = sk_to_full_sk(sk);
>  		if (!sk_fullsock(sk)) {
> -			if (!sock_flag(sk, SOCK_RCU_FREE))
> -				sock_gen_put(sk);
> +			__bpf_sk_release(sk);
>  			return NULL;
>  		}
>  	}
> @@ -5383,8 +5389,7 @@ static const struct bpf_func_proto bpf_sk_lookup_udp_proto = {
>  
>  BPF_CALL_1(bpf_sk_release, struct sock *, sk)
>  {
> -	if (!sock_flag(sk, SOCK_RCU_FREE))
> -		sock_gen_put(sk);
> +	__bpf_sk_release(sk);
>  	return 0;
>  }
>  
> -- 
> 2.20.1
> 

  reply	other threads:[~2020-01-09 18:24 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-09 11:57 [PATCH bpf 0/1] Fix memory leak in helpers dealing with sockets Lorenz Bauer
2020-01-09 11:57 ` [PATCH bpf 1/1] net: bpf: don't leak time wait and request sockets Lorenz Bauer
2020-01-09 18:23   ` Martin Lau [this message]
2020-01-10 13:27     ` Lorenz Bauer
2020-01-10 13:23 ` [PATCH bpf v2] " Lorenz Bauer
2020-01-10 16:43   ` Martin Lau
2020-01-10 18:45     ` Alexei Starovoitov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200109182335.um72tp73krvvubnl@kafai-mbp.dhcp.thefacebook.com \
    --to=kafai@fb.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=joe@isovalent.com \
    --cc=kernel-team@cloudflare.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lmb@cloudflare.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.