| Message ID | 20210831165802.168776-1-toke@redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | [bpf] libbpf: don't crash on object files with no symbol tables | expand |
On Tue, Aug 31, 2021 at 9:58 AM Toke Høiland-Jørgensen <toke@redhat.com> wrote: > > If libbpf encounters an ELF file that has been stripped of its symbol > table, it will crash in bpf_object__add_programs() when trying to > dereference the obj->efile.symbols pointer. Add a check and return to avoid > this. > > Fixes: 6245947c1b3c ("libbpf: Allow gaps in BPF program sections to support overriden weak functions") > Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com> > --- > tools/lib/bpf/libbpf.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c > index 6f5e2757bb3c..4cd102affeef 100644 > --- a/tools/lib/bpf/libbpf.c > +++ b/tools/lib/bpf/libbpf.c > @@ -668,6 +668,9 @@ bpf_object__add_programs(struct bpf_object *obj, Elf_Data *sec_data, > const char *name; > GElf_Sym sym; > > + if (!symbols) > + return -ENOENT; > + The more logical place to do this check is in bpf_object__elf_collect(). Can you add this there? We can also include helpful error message. But I'm also curious which Clang version is being used to cause no ELF symbols being generated? > progs = obj->programs; > nr_progs = obj->nr_programs; > nr_syms = symbols->d_size / sizeof(GElf_Sym); > -- > 2.33.0 >
Andrii Nakryiko <andrii.nakryiko@gmail.com> writes: > On Tue, Aug 31, 2021 at 9:58 AM Toke Høiland-Jørgensen <toke@redhat.com> wrote: >> >> If libbpf encounters an ELF file that has been stripped of its symbol >> table, it will crash in bpf_object__add_programs() when trying to >> dereference the obj->efile.symbols pointer. Add a check and return to avoid >> this. >> >> Fixes: 6245947c1b3c ("libbpf: Allow gaps in BPF program sections to support overriden weak functions") >> Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com> >> --- >> tools/lib/bpf/libbpf.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c >> index 6f5e2757bb3c..4cd102affeef 100644 >> --- a/tools/lib/bpf/libbpf.c >> +++ b/tools/lib/bpf/libbpf.c >> @@ -668,6 +668,9 @@ bpf_object__add_programs(struct bpf_object *obj, Elf_Data *sec_data, >> const char *name; >> GElf_Sym sym; >> >> + if (!symbols) >> + return -ENOENT; >> + > > The more logical place to do this check is in > bpf_object__elf_collect(). Can you add this there? We can also include > helpful error message. Sure, can do. > But I'm also curious which Clang version is being used to cause no ELF > symbols being generated? It's not Clang. I was debugging an issue with 'strip' mangling BPF object files and ran into this after trying to load an object file that had been run through a full 'strip bpf_object.o' (whereas 'strip -g bpf_object.o' works fine, except for that one bug I'm looking at). -Toke
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c index 6f5e2757bb3c..4cd102affeef 100644 --- a/tools/lib/bpf/libbpf.c +++ b/tools/lib/bpf/libbpf.c @@ -668,6 +668,9 @@ bpf_object__add_programs(struct bpf_object *obj, Elf_Data *sec_data, const char *name; GElf_Sym sym; + if (!symbols) + return -ENOENT; + progs = obj->programs; nr_progs = obj->nr_programs; nr_syms = symbols->d_size / sizeof(GElf_Sym);
If libbpf encounters an ELF file that has been stripped of its symbol table, it will crash in bpf_object__add_programs() when trying to dereference the obj->efile.symbols pointer. Add a check and return to avoid this. Fixes: 6245947c1b3c ("libbpf: Allow gaps in BPF program sections to support overriden weak functions") Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com> --- tools/lib/bpf/libbpf.c | 3 +++ 1 file changed, 3 insertions(+)