DEBIAN-CVE-2022-50450

In the Linux kernel, the following vulnerability has been resolved: libbpf: Use elfgetshdrnum() instead of eshnum This commit replace eshnum with the elfgetshdrnum() helper to fix two oss-fuzz-reported heap-buffer overflow in bpf_objectopen. 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: seccnt 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 bpfobjectelfcollect /src/libbpf/src/libbpf.c:3414:24 #1 0x5733c0 in bpfobjectopen /src/libbpf/src/libbpf.c:7223:16 #2 0x5739fd in bpfobjectopenmem /src/libbpf/src/libbpf.c:7263:20 ... The issue lie in libbpf's direct use of eshnum field in ELF header as the section header count. Where as libelf implemented an extra logic that, when eshnum == 0 && eshoff != 0, will use shsize 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 SHNLORESERVE). The above inconsistency lead to libbpf writing into a zero-entry calloc area. So intead of using eshnum directly, use the elfgetshdrnum() helper provided by libelf to retrieve the section header counter into sec_cnt.