linux-kernel - Re: CVE-2022-50450: libbpf: Use elf_getshdrnum() instead of e

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <2025100912-ambiguity-emblem-1f96@gregkh>
Date: Thu, 9 Oct 2025 07:55:57 +0200
From: Greg Kroah-Hartman <gregkh@...nel.org>
To: Shung-Hsi Yu <shung-hsi.yu@...e.com>
Cc: cve@...nel.org, linux-kernel@...r.kernel.org,
	linux-cve-announce@...r.kernel.org,
	João Póvoas <joao.povoas@...e.com>
Subject: Re: CVE-2022-50450: libbpf: Use elf_getshdrnum() instead of e_shnum

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@...nel.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