Re: [PATCH bpf-next v1 1/8] resolve_btfids: Implement generic ensure_mem() to grow arrays

[Ihor Solodrai <ihor.solodrai@linux.dev>]

On 7/22/26 4:48 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] Strict aliasing violation via `void **` casting leading to potential Use-After-Free.
> --
> 
> --- Patch [1]: [PATCH bpf-next v1 1/8] resolve_btfids: Implement generic ensure_mem() to grow arrays ---
> commit b5970d9bf6b1262c4ad812706df67f4a14ee5411
> Author: Ihor Solodrai <ihor.solodrai@linux.dev>
> 
> resolve_btfids: Implement generic ensure_mem() to grow arrays
> 
> This commit factors out array growth logic from push_*() helpers into a
> generic ensure_mem() macro and function. It uses a void ** cast to update
> the array pointer upon reallocation.
> 
>> diff --git a/tools/bpf/resolve_btfids/main.c b/tools/bpf/resolve_btfids/main.c
>> index f8a91fa7584f4..183466ddc5f97 100644
>> --- a/tools/bpf/resolve_btfids/main.c
>> +++ b/tools/bpf/resolve_btfids/main.c
>> @@ -201,6 +201,35 @@ static int eprintf(int level, int var, const char *fmt, ...)
>>  #define pr_info(fmt, ...) \
>>  	eprintf(0, verbose, pr_fmt(fmt), ##__VA_ARGS__)
>>  
>> +/*
>> + * Grow *data so it can hold at least cnt elements of elem_sz bytes each.
>> + * *cap is the capacity in elements and is updated on growth.
>> + */
>> +static int __ensure_mem(void **data, u32 *cap, u32 cnt, size_t elem_sz)
>> +{
>> +	u32 new_cap, old_cap = *cap;
>> +	void *arr;
>> +
>> +	if (cnt <= old_cap)
>> +		return 0;
>> +
>> +	new_cap = max(old_cap + 256, old_cap * 2);
>> +	if (new_cap < cnt)
>> +		new_cap = cnt;
>> +
>> +	arr = realloc(*data, elem_sz * new_cap);
>> +	if (!arr)
>> +		return -ENOMEM;
>> +
>> +	*data = arr;
> 
> [Severity: Medium]
> Will this assignment violate strict aliasing rules? Because void * and u32 *
> are incompatible types, modifying the pointer through a void ** pointer
> violates C strict aliasing.
> 
> While core kernel code is compiled with -fno-strict-aliasing, programs under
> tools/ are compiled with standard optimizations including -fstrict-aliasing.
> If __ensure_mem() is inlined, could the compiler assume that this assignment
> does not modify the original typed pointer?

ensure_mem() is modeled on libbpf's own libbpf_ensure_mem(), which is
called exactly this way throughout libbpf with typed pointers cast to
(void **), built under the same tools/ flags.

The pattern is long-established and hasn't caused issues in practice.
Callers re-read the struct member after the call. Wontfix.

> 
>> +	*cap = new_cap;
>> +
>> +	return 0;
>> +}
>> +
>> +#define ensure_mem(arr_ptr, cap_ptr, cnt) \
>> +	__ensure_mem((void **)(arr_ptr), (cap_ptr), (cnt), sizeof(**(arr_ptr)))
> 
> [...]
>