mbox series

[bpf,0/3] libbpf: fix fuzzer-reported issues

Message ID 20221007174816.17536-1-shung-hsi.yu@suse.com (mailing list archive)
Headers show
Series libbpf: fix fuzzer-reported issues | expand

Message

Shung-Hsi Yu Oct. 7, 2022, 5:48 p.m. UTC 
Hi, this patch set fixes several fuzzer-reported issues of libbpf when
dealing with (malformed) BPF object file.

The 1st patch fix out-of-bound heap write reported by oss-fuzz
(currently incorrectly marked as fixed). The 2nd and 3rd patch fix
null-pointer dereference found by locally-run fuzzer.

Suggest at least taking the 1st fix in this patch set or apply an
alternative fix for it (see the extra note after its commit message for
detail).

Shung-Hsi Yu (3):
  libbpf: use elf_getshdrnum() instead of e_shnum
  libbpf: fix null-pointer dereference in find_prog_by_sec_insn()
  libbpf: deal with section with no data gracefully

 tools/lib/bpf/libbpf.c | 19 ++++++++++++++++---
 1 file changed, 16 insertions(+), 3 deletions(-)


base-commit: 0326074ff4652329f2a1a9c8685104576bd8d131
--
2.37.3

Comments

Andrii Nakryiko Oct. 11, 2022, 12:47 a.m. UTC | #1 
On Fri, Oct 7, 2022 at 10:48 AM Shung-Hsi Yu <shung-hsi.yu@suse.com> wrote:
>
> Hi, this patch set fixes several fuzzer-reported issues of libbpf when
> dealing with (malformed) BPF object file.
>
> The 1st patch fix out-of-bound heap write reported by oss-fuzz
> (currently incorrectly marked as fixed). The 2nd and 3rd patch fix
> null-pointer dereference found by locally-run fuzzer.
>
> Suggest at least taking the 1st fix in this patch set or apply an
> alternative fix for it (see the extra note after its commit message for
> detail).
>
> Shung-Hsi Yu (3):
>   libbpf: use elf_getshdrnum() instead of e_shnum
>   libbpf: fix null-pointer dereference in find_prog_by_sec_insn()
>   libbpf: deal with section with no data gracefully
>
>  tools/lib/bpf/libbpf.c | 19 ++++++++++++++++---
>  1 file changed, 16 insertions(+), 3 deletions(-)
>
>
> base-commit: 0326074ff4652329f2a1a9c8685104576bd8d131
> --
> 2.37.3
>

LGTM, but see my comment on patch #1. If that suggestion makes sense
and will work, please send v2. But base it on top of bpf-next, I don't
think there is any need to base this on bpf tree. Thanks.