Re: [PATCH] libbpf: fix weak kfunc name suffix resolution for light skeletons

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Resolving weak kfuncs to their essential names in light skeletons breaks backwards-compatibility fallbacks and can cause silent garbage injection into kernel functions.
--

commit 4f2d3782567ee95facb86d9351ef9b20032be805
Author: Siddharth Nayyar <sidnayyar@google.com>
Subject: libbpf: fix weak kfunc name suffix resolution for light skeletons

When generating a light skeleton, libbpf currently records the unstripped
name of kfuncs into the external symbol records. This commit changes
bpf_program_record_relos to pass ext->essent_name when calling
bpf_gen__record_extern for BTF_KIND_FUNC, stripping suffixes so the kernel
resolves them properly.

> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index 1368752aa13c3..421bfd5e159d1 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -8309,19 +8309,25 @@ static int bpf_program_record_relos(struct bpf_program *prog)
>  		struct reloc_desc *relo = &prog->reloc_desc[i];
>  		struct extern_desc *ext = &obj->externs[relo->ext_idx];
>  		int kind;
> +		const char *name;
>  
>  		switch (relo->type) {
>  		case RELO_EXTERN_LD64:
>  			if (ext->type != EXT_KSYM)
>  				continue;
> -			kind = btf_is_var(btf__type_by_id(obj->btf, ext->btf_id)) ?
> -				BTF_KIND_VAR : BTF_KIND_FUNC;
> -			bpf_gen__record_extern(obj->gen_loader, ext->name,
> +			if (btf_is_var(btf__type_by_id(obj->btf, ext->btf_id))) {
> +				kind = BTF_KIND_VAR;
> +				name = ext->name;
> +			} else {
> +				kind = BTF_KIND_FUNC;
> +				name = ext->essent_name ?: ext->name;
> +			}
> +			bpf_gen__record_extern(obj->gen_loader, name,
>  					       ext->is_weak, !ext->ksym.type_id,
>  					       true, kind, relo->insn_idx);
>  			break;
>  		case RELO_EXTERN_CALL:
> -			bpf_gen__record_extern(obj->gen_loader, ext->name,
> +			bpf_gen__record_extern(obj->gen_loader, ext->essent_name ?: ext->name,
>  					       ext->is_weak, false, false, BTF_KIND_FUNC,
>  					       relo->insn_idx);
>  			break;

[Severity: High]
By resolving weak kfuncs to their essential names instead of their suffixed
names here in RELO_EXTERN_CALL and RELO_EXTERN_LD64 above, does this break
backward compatibility fallbacks in light skeletons?

If a BPF program uses bpf_ksym_exists() to fall back to an older prototype
(e.g., calling func___v1 which takes 1 argument) but the kernel provides a
newer prototype without the suffix (taking 2 arguments), this would resolve
successfully because prototype validation against the suffix is bypassed.

Would the BPF verifier then accept a program calling the kfunc with only
R1 set, causing the kernel to execute the function with uninitialized or
garbage data in R2? Alternatively, if the verifier rejects the incompatible
register state, wouldn't this entirely break the intended backward
compatibility logic?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260622-bpf-lskel-fixes-v1-1-7c09a1585ba4@google.com?part=1