[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAADnVQKYv1YAv_jwQLHQYKdEcJCioKG0AfWRnGmwO=jqL9+jdw@mail.gmail.com>
Date: Tue, 22 Oct 2019 22:00:54 -0700
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Daniel Borkmann <daniel@...earbox.net>
Cc: Alexei Starovoitov <ast@...nel.org>, bpf <bpf@...r.kernel.org>,
Network Development <netdev@...r.kernel.org>,
Yonghong Song <yhs@...com>, Martin KaFai Lau <kafai@...com>
Subject: Re: [PATCH bpf] bpf: Fix use after free in bpf_get_prog_name
On Tue, Oct 22, 2019 at 2:30 PM Daniel Borkmann <daniel@...earbox.net> wrote:
>
> There is one more problematic case I noticed while recently fixing BPF kallsyms
> handling in cd7455f1013e ("bpf: Fix use after free in subprog's jited symbol
> removal") and that is bpf_get_prog_name().
>
> If BTF has been attached to the prog, then we may be able to fetch the function
> signature type id in kallsyms through prog->aux->func_info[prog->aux->func_idx].type_id.
> However, while the BTF object itself is torn down via RCU callback, the prog's
> aux->func_info is immediately freed via kvfree(prog->aux->func_info) once the
> prog's refcount either hit zero or when subprograms were already exposed via
> kallsyms and we hit the error path added in 5482e9a93c83 ("bpf: Fix memleak in
> aux->func_info and aux->btf").
>
> This violates RCU as well since kallsyms could be walked in parallel where we
> could access aux->func_info. Hence, defer kvfree() to after RCU grace period.
> Looking at ba64e7d85252 ("bpf: btf: support proper non-jit func info") there
> is no reason/dependency where we couldn't defer the kvfree(aux->func_info) into
> the RCU callback.
>
> Fixes: 5482e9a93c83 ("bpf: Fix memleak in aux->func_info and aux->btf")
> Fixes: ba64e7d85252 ("bpf: btf: support proper non-jit func info")
> Signed-off-by: Daniel Borkmann <daniel@...earbox.net>
> Cc: Yonghong Song <yhs@...com>
> Cc: Martin KaFai Lau <kafai@...com>
Applied. Thanks!
Powered by blists - more mailing lists