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.
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.
Thanks!
--
Michal Hocko
SUSE Labs
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.)
thanks,
greg k-h
On Thu, Mar 7, 2024 at 5:16 AM Greg Kroah-Hartman
<[email protected]> 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.
[0] https://github.com/libbpf/libbpf
>
> thanks,
>
> greg k-h
On Thu 07-03-24 13:16:26, Greg KH wrote:
[...]
> > 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.
I really do not want to nit pick here but the documentation doesn't talk
about tools:
: The Linux kernel developer team does have the ability to assign CVEs for
: potential Linux kernel security issues.
[...]
: Process
: =======
:
: As part of the normal stable release process, kernel changes that are
: potentially security issues are identified by the developers responsible
: for CVE number assignments and have CVE numbers automatically assigned
: to them.
So it is quite natural to ask whether this has been a patern matching
not working properly.
> > 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?
Well, is it? It surely makes the code more robust but that would be the
case for almost any bug fix. Killing a misbheaving application (whether it
uses libbpf or any other library) is an expected behavior. But maybe BPF
developers can give us some useful insight.
--
Michal Hocko
SUSE Labs
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
> <[email protected]> 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