Re: [PATCH bpf-next v1 06/14] resolve_btfids: Discover kfuncs from BTF ID sets

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

On 6/1/26 3:33 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] Ambiguous string-based lookup in resolve_btfids incorrectly resolves kfunc BTF IDs on name collisions, causing silent failures in BTF mutation and tag emission.
> --
> 
> commit 8f8fb9808a6cbcfa547c7cbbeadbb0e70e3b6b81
> Author: Ihor Solodrai <ihor.solodrai@linux.dev>
> 
> resolve_btfids: Discover kfuncs from BTF ID sets
> 
> This commit updates resolve_btfids to discover kfuncs by parsing BTF_ID_SET8
> symbols instead of relying on bpf_kfunc decl tags. It extracts the kfunc name
> from the symbol address, then looks up the BTF ID by name and records the
> associated flags.
> 
>> diff --git a/tools/bpf/resolve_btfids/main.c b/tools/bpf/resolve_btfids/main.c
>> index 43512af131482..d35a7b2460e83 100644
>> --- a/tools/bpf/resolve_btfids/main.c
>> +++ b/tools/bpf/resolve_btfids/main.c
> [ ... ]
>> @@ -1003,92 +1020,63 @@ static int collect_decl_tags(struct btf2btf_context *ctx)
> [ ... ]
>> +static int collect_kfuncs(struct object *obj, struct btf2btf_context *ctx)
>> +{
> [ ... ]
>> +		for (u32 i = 0; i < set_id->cnt; i++) {
>> +			Elf64_Addr addr = set_addr + sizeof(u64) * (i + 1);
>> +			const char *name = find_name_by_addr(obj, addr);
>> +			struct kfunc kfunc;
>> +			s32 func_id;
>>  
>> -			if (!name || strcmp(name, kfunc_id->name) != 0)
>> +			if (!name) {
>> +				pr_err("WARN: resolve_btfids: no kfunc symbol for set %s entry %u\n",
>> +				       set_id->name, i);
>> +				warnings++;
>>  				continue;
>> +			}
>>  
>> -			pr_debug("found kfunc %s in BTF_ID_FLAGS %s\n",
>> -				 kfunc_id->name, set_id->name);
> [ ... ]
>> +			func_id = btf__find_by_name_kind(btf, name, BTF_KIND_FUNC);
> 
> [Severity: High]
> Does this string-based lookup risk returning the wrong BTF ID when processing
> kernel modules?
> 
> When resolve_btfids processes a kernel module, btf__find_by_name_kind() searches
> the base_btf (vmlinux BTF) before the module's BTF. If a module kfunc shares
> a name with a static function in vmlinux, or if there are multiple static
> functions with the same name within the module, it seems this might return an
> incorrect BTF ID.

I am not convinced this is an issue, because a module kfunc shadowing a kernel
kfunc by name seems to me like a bad idea at first glance.

Still, AI might be onto something here. I'll experiment with bpf test module in
the selftests to investigate.

> 
> If the wrong BTF ID is returned, resolve_btfids could silently mutate the wrong
> type in memory later, for example in process_kfunc_with_implicit_args() or
> process_kfunc_with_arena_flags(). Since base_btf modifications are not saved to
> the module's .BTF section, the actual module kfunc would remain unmodified. Will
> this cause the BPF verifier to reject programs using the module kfunc due to
> missing implicit args removal or tags?
> 
>> +			if (func_id < 0) {
>> +				pr_err("WARN: resolve_btfids: no BTF FUNC for kfunc %s in set %s\n",
>> +				       name, set_id->name);
>> +				warnings++;
>> +				continue;
>> +			}
>