Re: [PATCH v3 1/2] net: Fix possible race in peernet2id_alloc()

[David Miller <davem@davemloft.net>]

From: Kirill Tkhai <ktkhai@virtuozzo.com>
Date: Tue, 16 Jan 2018 12:31:41 +0300

> peernet2id_alloc() is racy without rtnl_lock() as refcount_read(&peer->count)
> under net->nsid_lock does not guarantee, peer is alive:
> 
> rcu_read_lock()
> peernet2id_alloc()                            ..
>   spin_lock_bh(&net->nsid_lock)               ..
>   refcount_read(&peer->count) (!= 0)          ..
>   ..                                          put_net()
>   ..                                            cleanup_net()
>   ..                                              for_each_net(tmp)
>   ..                                                spin_lock_bh(&tmp->nsid_lock)
>   ..                                                __peernet2id(tmp, net) == -1
>   ..                                                    ..
>   ..                                                    ..
>     __peernet2id_alloc(alloc == true)                   ..
>   ..                                                    ..
> rcu_read_unlock()                                       ..
> ..                                                synchronize_rcu()
> ..                                                kmem_cache_free(net)
> 
> After the above situation, net::netns_id contains id pointing to freed memory,
> and any other dereferencing by the id will operate with this freed memory.
> 
> Currently, peernet2id_alloc() is used under rtnl_lock() everywhere except
> ovs_vport_cmd_fill_info(), and this race can't occur. But peernet2id_alloc()
> is generic interface, and better we fix it before someone really starts
> use it in wrong context.
> 
> v2: Don't place refcount_read(&net->count) under net->nsid_lock
>     as suggested by Eric W. Biederman <ebiederm@xmission.com>
> v3: Rebase on top of net-next
> 
> Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>

Applied to net-next.