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

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

[Greg Kroah-Hartman]

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.


Affected and fixed versions
===========================

	Fixed in 5.15.149 with commit 90dbf4535668
	Fixed in 6.1.77 with commit 12473265f50c
	Fixed in 6.6.16 with commit 5f3e436832e8
	Fixed in 6.7.4 with commit ab26541270c7
	Fixed in 6.8-rc1 with commit fc3a5534e2a8

Please see https://www.kernel.org or a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2023-52592
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	tools/lib/bpf/libbpf.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/90dbf4535668042fac0d7201ce9e2c8c770c578a
	https://git.kernel.org/stable/c/12473265f50c1e27b0dfd9735738ac418c4bfcce
	https://git.kernel.org/stable/c/5f3e436832e86b826a6450eb8d1aaa51205a758e
	https://git.kernel.org/stable/c/ab26541270c722eedf8eefd62797c3ce3d18a91b
	https://git.kernel.org/stable/c/fc3a5534e2a8855427403113cbeb54af5837bbe0

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

[Michal Hocko]

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

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

[Greg Kroah-Hartman]

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

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

[Michal Hocko]

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

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

[Andrii Nakryiko]

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.

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

>
> thanks,
>
> greg k-h

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

[Greg Kroah-Hartman]

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

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

[Greg Kroah-Hartman]

CVE-2023-52592 has now been rejected and is no longer a valid CVE.