Received-SPF: pass (google.com: domain of linux-kernel+bounces-95975-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Precedence: bulk
MIME-Version: 1.0
References: <2024030645-CVE-2023-52592-4693@gregkh> <ZemPuxhM_ZZ-khTh@tiehlicka>
 <2024030706-unscathed-wilt-e310@gregkh>
In-Reply-To: <2024030706-unscathed-wilt-e310@gregkh>
From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Date: Thu, 7 Mar 2024 09:50:38 -0800
Message-ID: <CAEf4BzbvmwmAmZMvzo9gxyUwy9SQvC_2gFQ1wO-Zvw=9BT=J2g@mail.gmail.com>
Subject: Re: CVE-2023-52592: libbpf: Fix NULL pointer dereference in bpf_object__collect_prog_relos
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Michal Hocko <mhocko@suse.com>, cve@kernel.org, linux-kernel@vger.kernel.org, 
	Alexei Starovoitov <ast@kernel.org>, Daniel Borkmann <daniel@iogearbox.net>, 
	Andrii Nakryiko <andrii@kernel.org>, Martin KaFai Lau <martin.lau@linux.dev>, Song Liu <song@kernel.org>, 
	Yonghong Song <yonghong.song@linux.dev>, John Fastabend <john.fastabend@gmail.com>, 
	KP Singh <kpsingh@kernel.org>, Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>, 
	Jiri Olsa <jolsa@kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Mar 7, 2024 at 5:16=E2=80=AFAM 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
> > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > >
> > > In the Linux kernel, the following vulnerability has been resolved:
> > >
> > > libbpf: Fix NULL pointer dereference in bpf_object__collect_prog_relo=
s
> > >
> > > An issue occurred while reading an ELF file in libbpf.c during fuzzin=
g:
> > >
> > >     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 libb=
pf.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-ob=
ject-fuzzer.c:16
> > >     #5 0x000000000060be11 in testblitz_engine::fuzzer::Fuzzer::run_on=
e ()
> > >     #6 0x000000000087ad92 in tracing::span::Span::in_scope ()
> > >     #7 0x00000000006078aa in testblitz_engine::fuzzer::util::walkdir =
()
> > >     #8 0x00000000005f3217 in testblitz_engine::entrypoint::main::{{cl=
osure}} ()
> > >     #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 >=3D scn_data->d=
_size) {
> > >
> > > The scn_data is derived from the code above:
> > >
> > >     scn =3D elf_sec_by_idx(obj, sec_idx);
> > >     scn_data =3D elf_sec_data(obj, scn);
> > >
> > >     relo_sec_name =3D elf_sec_str(obj, shdr->sh_name);
> > >     sec_name =3D elf_sec_name(obj, scn);
> > >     if (!relo_sec_name || !sec_name)// don't check whether scn_data i=
s 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 t=
o
> > 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.

  [0] https://github.com/libbpf/libbpf

>
> thanks,
>
> greg k-h