All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
To: David Miller <davem@davemloft.net>
Cc: daniel@iogearbox.net, eric.dumazet@gmail.com,
	alexei.starovoitov@gmail.com, mkubecek@suse.cz,
	sasha.levin@oracle.com, jslaby@suse.cz, mst@redhat.com,
	netdev@vger.kernel.org
Subject: Re: [PATCH net] tun, bpf: fix suspicious RCU usage in tun_{attach,detach}_filter
Date: Thu, 31 Mar 2016 21:48:27 +0200	[thread overview]
Message-ID: <56FD7F0B.5090602@stressinduktion.org> (raw)
In-Reply-To: <20160331.153630.1640223846173244431.davem@davemloft.net>

On 31.03.2016 21:36, David Miller wrote:
> From: Hannes Frederic Sowa <hannes@stressinduktion.org>
> Date: Thu, 31 Mar 2016 21:24:12 +0200
>
>> diff --git a/net/core/filter.c b/net/core/filter.c
>> index 4b81b71171b4ce..8ab270d5ce5507 100644
>> --- a/net/core/filter.c
>> +++ b/net/core/filter.c
>> @@ -1166,7 +1166,8 @@ static int __sk_attach_prog(struct bpf_prog
>> *prog, struct sock *sk)
>>   	}
>>
>>   	old_fp = rcu_dereference_protected(sk->sk_filter,
>> -					   sock_owned_by_user(sk));
>> +					   lockdep_rtnl_is_held() ||
>> +					   lockdep_sock_is_held(sk));
>>   	rcu_assign_pointer(sk->sk_filter, fp);
>>
>>   	if (old_fp)
>
> I have the same objections Daniel did.
>
> Not all socket filter clients use RTNL as the synchornization
> mechanism.  The caller, or some descriptive element, should tell us
> what that synchronizing element is.
>
> Yes, I understand how these RTNL checks can pass "accidently" but
> the opposite is true too.  A socket locking synchornizing user,
> who didn't lock the socket, might now pass because RTNL happens
> to be held elsewhere.

Actually lockdep_rtnl_is_held checks if this specific code/thread holds 
the lock and no other cpu/thread. So it will not pass here in case 
another cpu has the lock.

lockdep stores the current held locks in current->held_locks, if we 
preempt we switch current pointer, if we take a spin_lock we can't sleep 
thus not preempt. Thus we always know that this specific code has the lock.

Using sock_owned_by_user actually has this problem, and thus I am 
replacing it. We don't know who has the socket locked.

Tightest solution would probably be to combine both patches.

bool called_by_tuntap;

old_fp = rcu_dereference_protected(sk->sk_filter, called_by_tuntap ? 
lockdep_rtnl_is_held() : lockdep_sock_is_held());

Bye,
Hannes

  reply	other threads:[~2016-03-31 19:48 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-31  0:13 [PATCH net] tun, bpf: fix suspicious RCU usage in tun_{attach,detach}_filter Daniel Borkmann
2016-03-31  1:18 ` Alexei Starovoitov
2016-03-31  5:01   ` Michal Kubecek
2016-03-31  5:08     ` Alexei Starovoitov
2016-03-31  5:22       ` Michal Kubecek
2016-03-31  5:43         ` Alexei Starovoitov
2016-03-31 11:35           ` Daniel Borkmann
2016-03-31 11:59             ` Eric Dumazet
2016-03-31 12:16               ` Daniel Borkmann
2016-03-31 19:21                 ` David Miller
2016-03-31 19:24                   ` Hannes Frederic Sowa
2016-03-31 19:31                     ` Alexei Starovoitov
2016-03-31 19:48                       ` David Miller
2016-03-31 19:36                     ` David Miller
2016-03-31 19:48                       ` Hannes Frederic Sowa [this message]
2016-03-31 19:50                         ` David Miller
2016-03-31 21:52                         ` Daniel Borkmann
2016-03-31 23:31                           ` Hannes Frederic Sowa
2016-03-31 12:12           ` Hannes Frederic Sowa
2016-03-31  9:15 ` Jiri Slaby

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=56FD7F0B.5090602@stressinduktion.org \
    --to=hannes@stressinduktion.org \
    --cc=alexei.starovoitov@gmail.com \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=jslaby@suse.cz \
    --cc=mkubecek@suse.cz \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=sasha.levin@oracle.com \
    /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.