linux-kernel - Re: [PATCH] libbpf: avoid possible use of uninitialized mod

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <49c6b3ba-7860-4b13-944f-5f503eb201fd@linux.dev>
Date: Tue, 29 Jul 2025 09:17:34 -0700
From: Yonghong Song <yonghong.song@...ux.dev>
To: Achill Gilgenast <fossdd@...ed.life>, Alexei Starovoitov
 <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>,
 Andrii Nakryiko <andrii@...nel.org>, Viktor Malik <vmalik@...hat.com>,
 bpf@...r.kernel.org
Cc: linux-kernel@...r.kernel.org, Martin KaFai Lau <martin.lau@...ux.dev>,
 Eduard Zingerman <eddyz87@...il.com>, Song Liu <song@...nel.org>,
 John Fastabend <john.fastabend@...il.com>, KP Singh <kpsingh@...nel.org>,
 Stanislav Fomichev <sdf@...ichev.me>, Hao Luo <haoluo@...gle.com>,
 Jiri Olsa <jolsa@...nel.org>
Subject: Re: [PATCH] libbpf: avoid possible use of uninitialized mod_len



On 7/29/25 2:45 AM, Achill Gilgenast wrote:
> If not fn_name, mod_len does never get initialized which fails now with
> gcc15 on Alpine Linux edge:
>
> 	libbpf.c: In function 'find_kernel_btf_id.constprop':
> 	libbpf.c:10100:33: error: 'mod_len' may be used uninitialized [-Werror=maybe-uninitialized]
> 	10100 |                 if (mod_name && strncmp(mod->name, mod_name, mod_len) != 0)
> 	      |                                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 	libbpf.c:10070:21: note: 'mod_len' was declared here
> 	10070 |         int ret, i, mod_len;
> 	      |                     ^~~~~~~
>
> Fixes: 8f8a024272f3 ("libbpf: support "module: Function" syntax for tracing programs")
> Signed-off-by: Achill Gilgenast <fossdd@...ed.life>

The code itself is actually okay. The error is triggered due to'maybe-uninitialized'.
To silence the compilation error, I think this change is okay.

Acked-by: Yonghong Song <yonghong.song@...ux.dev>

> ---
>   tools/lib/bpf/libbpf.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index e067cb5776bd..fb4d92c5c339 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -10086,27 +10086,27 @@ static int libbpf_find_prog_btf_id(const char *name, __u32 attach_prog_fd, int t
>   	btf__free(btf);
>   	if (err <= 0) {
>   		pr_warn("%s is not found in prog's BTF\n", name);
>   		goto out;
>   	}
>   out:
>   	return err;
>   }
>   
>   static int find_kernel_btf_id(struct bpf_object *obj, const char *attach_name,
>   			      enum bpf_attach_type attach_type,
>   			      int *btf_obj_fd, int *btf_type_id)
>   {
> -	int ret, i, mod_len;
> +	int ret, i, mod_len = 0;
>   	const char *fn_name, *mod_name = NULL;
>   
>   	fn_name = strchr(attach_name, ':');
>   	if (fn_name) {
>   		mod_name = attach_name;
>   		mod_len = fn_name - mod_name;
>   		fn_name++;
>   	}
>   
>   	if (!mod_name || strncmp(mod_name, "vmlinux", mod_len) == 0) {
>   		ret = find_attach_btf_id(obj->btf_vmlinux,
>   					 mod_name ? fn_name : attach_name,
>   					 attach_type);