Re: CVE-2023-52592: libbpf: Fix NULL pointer dereference in bpf_object__collect_prog_relos

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Thu, Mar 07, 2024 at 09:50:38AM -0800, Andrii Nakryiko wrote:
> On Thu, Mar 7, 2024 at 5:16 AM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > On Thu, Mar 07, 2024 at 10:58:19AM +0100, Michal Hocko wrote:
> > > On Wed 06-03-24 06:45:50, Greg KH wrote:
> > > > Description
> > > > ===========
> > > >
> > > > In the Linux kernel, the following vulnerability has been resolved:
> > > >
> > > > libbpf: Fix NULL pointer dereference in bpf_object__collect_prog_relos
> > > >
> > > > An issue occurred while reading an ELF file in libbpf.c during fuzzing:
> > > >
> > > >     Program received signal SIGSEGV, Segmentation fault.
> > > >     0x0000000000958e97 in bpf_object.collect_prog_relos () at libbpf.c:4206
> > > >     4206 in libbpf.c
> > > >     (gdb) bt
> > > >     #0 0x0000000000958e97 in bpf_object.collect_prog_relos () at libbpf.c:4206
> > > >     #1 0x000000000094f9d6 in bpf_object.collect_relos () at libbpf.c:6706
> > > >     #2 0x000000000092bef3 in bpf_object_open () at libbpf.c:7437
> > > >     #3 0x000000000092c046 in bpf_object.open_mem () at libbpf.c:7497
> > > >     #4 0x0000000000924afa in LLVMFuzzerTestOneInput () at fuzz/bpf-object-fuzzer.c:16
> > > >     #5 0x000000000060be11 in testblitz_engine::fuzzer::Fuzzer::run_one ()
> > > >     #6 0x000000000087ad92 in tracing::span::Span::in_scope ()
> > > >     #7 0x00000000006078aa in testblitz_engine::fuzzer::util::walkdir ()
> > > >     #8 0x00000000005f3217 in testblitz_engine::entrypoint::main::{{closure}} ()
> > > >     #9 0x00000000005f2601 in main ()
> > > >     (gdb)
> > > >
> > > > scn_data was null at this code(tools/lib/bpf/src/libbpf.c):
> > > >
> > > >     if (rel->r_offset % BPF_INSN_SZ || rel->r_offset >= scn_data->d_size) {
> > > >
> > > > The scn_data is derived from the code above:
> > > >
> > > >     scn = elf_sec_by_idx(obj, sec_idx);
> > > >     scn_data = elf_sec_data(obj, scn);
> > > >
> > > >     relo_sec_name = elf_sec_str(obj, shdr->sh_name);
> > > >     sec_name = elf_sec_name(obj, scn);
> > > >     if (!relo_sec_name || !sec_name)// don't check whether scn_data is NULL
> > > >             return -EINVAL;
> > > >
> > > > In certain special scenarios, such as reading a malformed ELF file,
> > > > it is possible that scn_data may be a null pointer
> > > >
> > > > The Linux kernel CVE team has assigned CVE-2023-52592 to this issue.
> > >
> > > OK, so this one is quite interesting. This is a userspace tooling
> > > gaining a kernel CVE. Is this just an omission or is this really
> > > expected.
> >
> > "omission"?  I don't understand the question.
> >
> > We are responsible for assigning CVEs to stuff that is in the "Linux
> > kernel source tree" (some have tried to get us to assign CVEs to
> > programs like git that are just hosted on kernel.org), so for now, yes,
> > this includes libbpf as well as stuff like perf.
> >
> > > Also what is the security threat model here? If a malformed ELF file is
> > > loaded then the process gets SEGV which is perfectly reasonable thing to
> > > do.
> >
> > Again, we do not do "threat modeling", we do "does this fix a weakness",
> > and I think this does as causing SEGV might not be a good thing, right?
> >
> > But we'll defer to the libbpf maintainers on this, if they feel this is
> > just a "normal bugfix" then we can revoke this (added them to the cc:
> > here.)
> 
> Libbpf isn't meant to be fed untrusted ELF files, as it's normally
> used under root to perform BPF operations. So we generally treat these
> issues of malformed ELF crashing libbpf as just normal bugs, not as a
> security vulnerability. We even had issues where libelf crashed before
> libbpf could do anything at all. But this happens only for
> fuzzer-generated artificial test cases. In practice compilers produce
> valid ELFs and that's what real world applications are ever going to
> use.
> 
> Also note, in-kernel libbpf sources are only used for kernel
> build-time tooling (resolve_btfids) and for running BPF selftests. In
> both cases incoming ELF files are valid and created in a controlled
> environment. All the out-of-kernel users are supposed to use Github
> mirror of libbpf ([0]), which is used for packing libbpf in distros.
> 
> tl;dr: I wouldn't assign CVE for such issues, thanks.

Ok, thanks, I'll go revoke this and we'll figure out a way to add the
libbpf stuff to our filters to not assign stuff in the future.

greg k-h