Re: [PATCH bpf-next v3 06/14] libbpf: Relocate pointers that are stored in arena

[Roman Gushchin <roman.gushchin@linux.dev>]

> On Nov 3, 2026, at 6:02 PM, Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> 
> On Tue, Nov 03, 2026 at 05:44 PM sashiko-bot@kernel.org <sashiko-bot@kernel.org> wrote:
>>> +    ptrs = libbpf_reallocarray(NULL, nrels, sizeof(*ptrs));
>>> +    if (!ptrs)
>>> +        return -ENOMEM;
>>> +    obj->arena_ptrs = ptrs;
> 
> [...]
> 
>> 1. If multiple SEC_RELO sections target arena_data_shndx, the second call
>> overwrites obj->arena_ptrs (leaking the prior allocation) and allocates only
>> nrels entries, while obj->arena_ptr_cnt holds the sum across both calls. When
>> bpf_object__create_maps() -> relocate_arena_ptrs() later runs:
> 
> Not a bug. Only a hand-made ELF has two SHT_REL sections for one section.
> clang emits one for .addr_space.1, and the static linker merges them by
> name in linker_append_elf_relos().
> 
>> 2. If an empty .rel.addr_space.1 section has sh_size == 0 (nrels == 0),
>> libbpf_reallocarray(NULL, 0, sizeof(*ptrs)) calls realloc(NULL, 0), which may
>> return NULL and cause bpf_object__collect_arena_relos() to return -ENOMEM.
> 
> No. Nothing emits an empty SHT_REL section.
> glibc returns a pointer for realloc(NULL, 0). Where it's NULL the open of
> such a file fails, and that's fine.
> 
> I'm replying to a bot hoping that Roman will teach it to learn from maintainers
> and stop reporting such bugs in libbpf where input is trusted.

Thanks, well appreciated!
It’s going into that direction, now at least it should not raise it again in next versions.