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

["Alexei Starovoitov" <alexei.starovoitov@gmail.com>]

On Wed Nov 4, 2026 at 2:32 AM UTC, Roman Gushchin wrote:
>> 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.

Thank you!