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

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] bpf_map__attach_struct_ops() and bpf_map__init_kern_struct_ops() can dereference a NULL map->st_ops pointer if the map type is manually set to BPF_MAP_TYPE_STRUCT_OPS or maliciously defined in an ELF file.
--

commit c643fee98cc31443df8f0acc1fcfd6c87f93a4f8
Author: Roman Gushchin <roman.gushchin@linux.dev>

libbpf: fix return value on memory allocation failure

This commit fixes the return value of bpf_map__attach_struct_ops() to
correctly return -ENOMEM instead of -EINVAL when memory allocation for
the link structure fails.

> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> --- 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);

[Severity: High]
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?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1779760876.git.zhuhui@kylinos.cn?part=3