On Tue, Oct 3, 2017 at 10:11 AM, Jesper Dangaard Brouer <bro...@redhat.com> wrote: > On Mon, 2 Oct 2017 12:41:28 -0400 > Craig Gallek <kraigatg...@gmail.com> wrote: > >> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c >> index 4f402dcdf372..28b300868ad7 100644 >> --- a/tools/lib/bpf/libbpf.c >> +++ b/tools/lib/bpf/libbpf.c >> @@ -580,7 +580,7 @@ bpf_object__init_kversion(struct bpf_object *obj, >> } >> >> static int >> -bpf_object__validate_maps(struct bpf_object *obj) >> +bpf_object__validate_maps(struct bpf_object *obj, int map_def_sz) >> { >> int i; >> >> @@ -595,9 +595,11 @@ bpf_object__validate_maps(struct bpf_object *obj) >> const struct bpf_map *a = &obj->maps[i - 1]; >> const struct bpf_map *b = &obj->maps[i]; >> >> - if (b->offset - a->offset < sizeof(struct bpf_map_def)) { >> - pr_warning("corrupted map section in %s: map \"%s\" >> too small\n", >> - obj->path, a->name); >> + if (b->offset - a->offset < map_def_sz) { >> + pr_warning("corrupted map section in %s: map \"%s\" >> too small " >> + "(%zd vs %d)\n", >> + obj->path, a->name, b->offset - a->offset, >> + map_def_sz); >> return -EINVAL; > > Hmm... one more comment. You have just coded handling of ELF > map_def_sz which are smaller in a safe manor, but here this case will > get rejected (in bpf_object__validate_maps). That cannot be the right > intend?
I think you are right, but my test program didn't catch this... Perhaps an off-by-one (I only used slightly smaller map_def sizes). I suppose this entire function is unnecessary now. Even the old version wouldn't catch the case where the last offset was out of bounds? > -- > Best regards, > Jesper Dangaard Brouer > MSc.CS, Principal Kernel Engineer at Red Hat > LinkedIn: http://www.linkedin.com/in/brouer