> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c > index ab2071fdd3e8..1e8688975d16 100644 > --- a/tools/lib/bpf/libbpf.c > +++ b/tools/lib/bpf/libbpf.c > @@ -13701,7 +13701,7 @@ struct bpf_link *bpf_map__attach_struct_ops(const > struct bpf_map *map) > > link = calloc(1, sizeof(*link)); > if (!link) > - return libbpf_err_ptr(-EINVAL); > + return libbpf_err_ptr(-ENOMEM); > > /* kern_vdata should be prepared during the loading phase. */ > err = bpf_map_update_elem(map->fd, &zero, map->st_ops->kern_vdata, 0);
This is a pre-existing issue, but can this dereference a NULL map->st_ops pointer? If a user manually changes a map's type to BPF_MAP_TYPE_STRUCT_OPS using bpf_map__set_type(), or if a malformed BPF object file defines a map in the .maps section with this type, map->st_ops is never allocated. The bpf_object_init_struct_ops() function only allocates st_ops for maps found in the .struct_ops and .struct_ops.link sections. Because bpf_map__is_struct_ops() only checks map->def.type, could a missing NULL check on map->st_ops here and in bpf_map__init_kern_struct_ops() lead to a crash when privileged daemons parse untrusted BPF ELF files? Reviewed-by lore thread: https://lore.kernel.org/bpf/[email protected]/ --- AI reviewed your patch. Please fix the bug or email reply why it's not a bug. See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md CI run summary: https://github.com/kernel-patches/bpf/actions/runs/26429228214
