Re: [RFC PATCH bpf-next v7 03/11] libbpf: fix return value on memory allocation failure

[bot+bpf-ci]

> 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/20260526024145.5309F1F000E9@xxxxxxxxxxxxxxx/


---
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