Re: CVE-2022-50450: libbpf: Use elf_getshdrnum() instead of e_shnum

Re: CVE-2022-50450: libbpf: Use elf_getshdrnum() instead of e_shnum

[Shung-Hsi Yu]

On Wed, Oct 01, 2025 at 01:45:20PM +0200, Greg Kroah-Hartman wrote:
> From: Greg Kroah-Hartman <gregkh@kernel.org>
> 
> Description
> ===========
> 
> In the Linux kernel, the following vulnerability has been resolved:
> 
> libbpf: Use elf_getshdrnum() instead of e_shnum
> 
> This commit replace e_shnum with the elf_getshdrnum() helper to fix two
> oss-fuzz-reported heap-buffer overflow in __bpf_object__open. Both
> reports are incorrectly marked as fixed and while still being
> reproducible in the latest libbpf.
> 
>   # clusterfuzz-testcase-minimized-bpf-object-fuzzer-5747922482888704
>   libbpf: loading object 'fuzz-object' from buffer
>   libbpf: sec_cnt is 0
>   libbpf: elf: section(1) .data, size 0, link 538976288, flags 2020202020202020, type=2
>   libbpf: elf: section(2) .data, size 32, link 538976288, flags 202020202020ff20, type=1
>   =================================================================
>   ==13==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6020000000c0 at pc 0x0000005a7b46 bp 0x7ffd12214af0 sp 0x7ffd12214ae8
>   WRITE of size 4 at 0x6020000000c0 thread T0
>   SCARINESS: 46 (4-byte-write-heap-buffer-overflow-far-from-bounds)
>       #0 0x5a7b45 in bpf_object__elf_collect /src/libbpf/src/libbpf.c:3414:24
>       #1 0x5733c0 in bpf_object_open /src/libbpf/src/libbpf.c:7223:16
>       #2 0x5739fd in bpf_object__open_mem /src/libbpf/src/libbpf.c:7263:20
>       ...
> 
> The issue lie in libbpf's direct use of e_shnum field in ELF header as
> the section header count. Where as libelf implemented an extra logic
> that, when e_shnum == 0 && e_shoff != 0, will use sh_size member of the
> initial section header as the real section header count (part of ELF
> spec to accommodate situation where section header counter is larger
> than SHN_LORESERVE).
> 
> The above inconsistency lead to libbpf writing into a zero-entry calloc
> area. So intead of using e_shnum directly, use the elf_getshdrnum()
> helper provided by libelf to retrieve the section header counter into
> sec_cnt.
> 
> The Linux kernel CVE team has assigned CVE-2022-50450 to this issue.

Hi Greg,

I'd like to dispute this CVE. The libbpf maintainer previously suggested
such issue are viewed as normal bug fix, and not be considered for CVE
assignment[1,2].

Quoting Andrii from previous discussion in "CVE-2023-52592: libbpf: Fix
NULL pointer dereference in bpf_object__collect_prog_relos"[1] below:

> 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.
> 
> ...
> 
> tl;dr: I wouldn't assign CVE for such issues, thanks.

1: https://lore.kernel.org/all/CAEf4BzbvmwmAmZMvzo9gxyUwy9SQvC_2gFQ1wO-Zvw=9BT=J2g@mail.gmail.com/
2: https://lore.kernel.org/all/CAEf4Bzb2S+1TonOp9UH86r0e6aGG2LEA4kwbQhJWr=9Xju=NEw@mail.gmail.com/

[...]

Re: CVE-2022-50450: libbpf: Use elf_getshdrnum() instead of e_shnum

[Greg Kroah-Hartman]

On Thu, Oct 09, 2025 at 01:31:32PM +0800, Shung-Hsi Yu wrote:
> On Wed, Oct 01, 2025 at 01:45:20PM +0200, Greg Kroah-Hartman wrote:
> > From: Greg Kroah-Hartman <gregkh@kernel.org>
> > 
> > Description
> > ===========
> > 
> > In the Linux kernel, the following vulnerability has been resolved:
> > 
> > libbpf: Use elf_getshdrnum() instead of e_shnum
> > 
> > This commit replace e_shnum with the elf_getshdrnum() helper to fix two
> > oss-fuzz-reported heap-buffer overflow in __bpf_object__open. Both
> > reports are incorrectly marked as fixed and while still being
> > reproducible in the latest libbpf.
> > 
> >   # clusterfuzz-testcase-minimized-bpf-object-fuzzer-5747922482888704
> >   libbpf: loading object 'fuzz-object' from buffer
> >   libbpf: sec_cnt is 0
> >   libbpf: elf: section(1) .data, size 0, link 538976288, flags 2020202020202020, type=2
> >   libbpf: elf: section(2) .data, size 32, link 538976288, flags 202020202020ff20, type=1
> >   =================================================================
> >   ==13==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6020000000c0 at pc 0x0000005a7b46 bp 0x7ffd12214af0 sp 0x7ffd12214ae8
> >   WRITE of size 4 at 0x6020000000c0 thread T0
> >   SCARINESS: 46 (4-byte-write-heap-buffer-overflow-far-from-bounds)
> >       #0 0x5a7b45 in bpf_object__elf_collect /src/libbpf/src/libbpf.c:3414:24
> >       #1 0x5733c0 in bpf_object_open /src/libbpf/src/libbpf.c:7223:16
> >       #2 0x5739fd in bpf_object__open_mem /src/libbpf/src/libbpf.c:7263:20
> >       ...
> > 
> > The issue lie in libbpf's direct use of e_shnum field in ELF header as
> > the section header count. Where as libelf implemented an extra logic
> > that, when e_shnum == 0 && e_shoff != 0, will use sh_size member of the
> > initial section header as the real section header count (part of ELF
> > spec to accommodate situation where section header counter is larger
> > than SHN_LORESERVE).
> > 
> > The above inconsistency lead to libbpf writing into a zero-entry calloc
> > area. So intead of using e_shnum directly, use the elf_getshdrnum()
> > helper provided by libelf to retrieve the section header counter into
> > sec_cnt.
> > 
> > The Linux kernel CVE team has assigned CVE-2022-50450 to this issue.
> 
> Hi Greg,
> 
> I'd like to dispute this CVE. The libbpf maintainer previously suggested
> such issue are viewed as normal bug fix, and not be considered for CVE
> assignment[1,2].
> 
> Quoting Andrii from previous discussion in "CVE-2023-52592: libbpf: Fix
> NULL pointer dereference in bpf_object__collect_prog_relos"[1] below:
> 
> > 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.
> > 
> > ...
> > 
> > tl;dr: I wouldn't assign CVE for such issues, thanks.

Very good point, sorry about that.  I should have caught this in the
re-review of these, my fault.  Will go reject this now, thanks for the
review!

greg k-h