netdev - Re: [PATCH net-next] bpf, mlx4: fix prog refcount in mlx4_en_try_alloc

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: <20161109215346.GA54489@ast-mbp.thefacebook.com>
Date:   Wed, 9 Nov 2016 13:53:48 -0800
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Daniel Borkmann <daniel@...earbox.net>
Cc:     davem@...emloft.net, bblanco@...mgrid.com, tariqt@...lanox.com,
        zhiyisun@...il.com, netdev@...r.kernel.org
Subject: Re: [PATCH net-next] bpf, mlx4: fix prog refcount in
 mlx4_en_try_alloc_resources error path

On Wed, Nov 09, 2016 at 10:02:34PM +0100, Daniel Borkmann wrote:
> Commit 67f8b1dcb9ee ("net/mlx4_en: Refactor the XDP forwarding rings
> scheme") added a bug in that the prog's reference count is not dropped
> in the error path when mlx4_en_try_alloc_resources() is failing from
> mlx4_xdp_set().
> 
> We previously took bpf_prog_add(prog, priv->rx_ring_num - 1), that we
> need to release again. Earlier in the call path, dev_change_xdp_fd()
> itself holds a reference to the prog as well (hence the '- 1' in the
> bpf_prog_add()), so a simple atomic_sub() is safe to use here. When
> an error is propagated, then bpf_prog_put() is called eventually from
> dev_change_xdp_fd()
> 
> Fixes: 67f8b1dcb9ee ("net/mlx4_en: Refactor the XDP forwarding rings scheme")
> Signed-off-by: Daniel Borkmann <daniel@...earbox.net>

Good catch. Thanks for the quick fix.

> +void bpf_prog_sub(struct bpf_prog *prog, int i)
> +{
> +	/* Only to be used for undoing previous bpf_prog_add() in some
> +	 * error path. We still know that another entity in our call
> +	 * path holds a reference to the program, thus atomic_sub() can
> +	 * be safely used in such cases!
> +	 */
> +	WARN_ON(atomic_sub_return(i, &prog->aux->refcnt) == 0);
> +}
> +EXPORT_SYMBOL_GPL(bpf_prog_sub);

to elaborate on this little bit further...
if we did it as an extension to bpf_prog_put(), like
  if (atomic_sub_return(i, &prog->aux->refcnt) == 0)
    call_rcu(&prog->aux->rcu, __bpf_prog_put_rcu);
it could be seen a 'safe' version and people would be tempted
to use without thinking,
but since right now bpf_prog_add() can be done only after bpf_prog_get(),
this bpf_prog_sub() matches bpf_prog_add() to clean up refcnt
in the error path, so having separate helper like this makes sense,
instead of overloading bpf_prog_sub into 'safe' bpf_prog_put variant.
So all looks correct to me.
Acked-by: Alexei Starovoitov <ast@...nel.org>