All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Ihor Solodrai" <ihor.solodrai@linux.dev>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v1 05/14] resolve_btfids: Index BTF ID symbols by address
Date: Mon, 01 Jun 2026 22:28:57 +0000	[thread overview]
Message-ID: <20260601222857.DFAB11F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260601221805.821394-6-ihor.solodrai@linux.dev>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] A maliciously crafted or empty symbol size can cause an integer underflow, leading to a 4-billion iteration loop.
- [Low] Calling qsort and bsearch with a NULL base pointer when the array is empty is Undefined Behavior.
--

commit e05f36e9d7ac18c038a5933609937a41496ecf8f
Author: Ihor Solodrai <ihor.solodrai@linux.dev>

resolve_btfids: Index BTF ID symbols by address

This commit introduces an address-sorted index for parsed .BTF_ids symbols.
It uses this index in find_kfunc_flags() to scan BTF_SET8_KFUNCS entries
directly and match each entry back to the requested kfunc.

> diff --git a/tools/bpf/resolve_btfids/main.c b/tools/bpf/resolve_btfids/main.c
> --- a/tools/bpf/resolve_btfids/main.c
> +++ b/tools/bpf/resolve_btfids/main.c

[ ... ]

> @@ -480,6 +489,49 @@ static int elf_collect(struct object *obj)
> +static const char *find_name_by_addr(struct object *obj, Elf64_Addr addr)
> +{
> +	struct addr_sym key = { .addr = addr };
> +	struct addr_sym *res;
> +
> +	res = bsearch(&key, obj->addr_syms, obj->nr_addr_syms,
> +		      sizeof(*obj->addr_syms), cmp_addr_sym);

[Severity: Low]
Could this call trigger Undefined Behavior if there are no BTF ID symbols?

If the ELF file lacks these symbols, obj->addr_syms remains NULL and
obj->nr_addr_syms is 0. Calling bsearch with a NULL base pointer is
Undefined Behavior under the C standard, which can cause issues with UBSan
builds.

> +	return res ? res->name : NULL;
> +}

[ ... ]

> @@ -573,8 +625,14 @@ static int symbols_collect(struct object *obj)
>  			return -1;
>  		}
>  		id->addr[id->addr_cnt++] = sym.st_value;
> +
> +		if (push_addr_sym(obj, sym.st_value, id->name))
> +			return -1;
>  	}
>  
> +	qsort(obj->addr_syms, obj->nr_addr_syms, sizeof(*obj->addr_syms),
> +	      cmp_addr_sym);

[Severity: Low]
Does this have the same NULL pointer issue as the bsearch call?

If the array is empty and obj->addr_syms is NULL, calling qsort here
triggers the same Undefined Behavior as described above.

> +
>  	return 0;
>  }

[ ... ]

> @@ -946,43 +1004,41 @@ static int collect_decl_tags(struct btf2btf_context *ctx)
>  static u32 find_kfunc_flags(struct object *obj, struct btf_id *kfunc_id)
>  {
>  	const u32 *elf_data_ptr = obj->efile.idlist->d_buf;
>  	struct btf_id *set_id;
>  	struct rb_node *next;
>  	u64 idx, set_addr;
>  	u32 set_flags;
>  
>  	for (next = rb_first(&obj->sets); next; next = rb_next(next)) {
>  		set_id = rb_entry(next, struct btf_id, rb_node);
>  		if (set_id->kind != BTF_ID_KIND_SET8 || set_id->addr_cnt != 1)
>  			continue;
>  
>  		set_addr = set_id->addr[0];
>  		idx = (set_addr - obj->efile.idlist_addr) / sizeof(u32) + 1;
>  		set_flags = elf_data_ptr[idx];
>  		if (!(set_flags & BTF_SET8_KFUNCS))
>  			continue;
>  
> -		for (u32 i = 0; i < kfunc_id->addr_cnt; i++) {
> -			addr = kfunc_id->addr[i];
> +		for (u32 i = 0; i < set_id->cnt; i++) {

[Severity: Medium]
Could this loop iterate billions of times if a symbol size is unexpectedly
small?

When parsing SET8 symbols, the count is calculated as:

id->cnt = sym.st_size / sizeof(uint64_t) - 1;

If sym.st_size is less than 8, id->cnt (which is a signed int) becomes -1.

Because the loop index 'i' is an unsigned 32-bit integer, the comparison
promotes the signed -1 to 0xFFFFFFFF. Will this cause the tool to hang
spinning through 4 billion iterations if it processes a corrupted or crafted
ELF object?

> +			Elf64_Addr addr = set_addr + sizeof(u64) * (i + 1);
> +			const char *name = find_name_by_addr(obj, addr);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260601221805.821394-1-ihor.solodrai@linux.dev?part=5

  reply	other threads:[~2026-06-01 22:28 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-01 22:17 [PATCH bpf-next v1 00/14] resolve_btfids: Implement BTF tags emission for kfuncs Ihor Solodrai
2026-06-01 22:17 ` [PATCH bpf-next v1 01/14] tools/bpf: Sync btf_ids.h to tools Ihor Solodrai
2026-06-01 22:17 ` [PATCH bpf-next v1 02/14] selftests/bpf: Modernize resolve_btfids test scaffolding Ihor Solodrai
2026-06-02 13:02   ` Jiri Olsa
2026-06-02 18:30     ` Ihor Solodrai
2026-06-01 22:17 ` [PATCH bpf-next v1 03/14] selftests/bpf: Fix resolve_btfids test reads of BTF ID sets in PIE builds Ihor Solodrai
2026-06-03 23:45   ` Andrii Nakryiko
2026-06-01 22:17 ` [PATCH bpf-next v1 04/14] selftests/bpf: Add kfunc set test to resolve_btfids Ihor Solodrai
2026-06-02 13:02   ` Jiri Olsa
2026-06-03 23:45   ` Andrii Nakryiko
2026-06-01 22:17 ` [PATCH bpf-next v1 05/14] resolve_btfids: Index BTF ID symbols by address Ihor Solodrai
2026-06-01 22:28   ` sashiko-bot [this message]
2026-06-01 23:03   ` bot+bpf-ci
2026-06-02 13:01   ` Jiri Olsa
2026-06-02 18:28     ` Ihor Solodrai
2026-06-03 23:45   ` Andrii Nakryiko
2026-06-01 22:17 ` [PATCH bpf-next v1 06/14] resolve_btfids: Discover kfuncs from BTF ID sets Ihor Solodrai
2026-06-01 22:33   ` sashiko-bot
2026-06-02 18:36     ` Ihor Solodrai
2026-06-02 20:36   ` Jiri Olsa
2026-06-02 21:08     ` Ihor Solodrai
2026-06-03 23:45       ` Andrii Nakryiko
2026-06-03 23:45   ` Andrii Nakryiko
2026-06-01 22:17 ` [PATCH bpf-next v1 07/14] resolve_btfids: Emit bpf_kfunc BTF decl tag for discovered kfuncs Ihor Solodrai
2026-06-03 23:45   ` Andrii Nakryiko
2026-06-01 22:17 ` [PATCH bpf-next v1 08/14] selftests/bpf: Verify bpf_kfunc decl tag emission in resolve_btfids Ihor Solodrai
2026-06-01 22:18 ` [PATCH bpf-next v1 09/14] resolve_btfids: Emit a decl tag for kfuncs with KF_FASTCALL Ihor Solodrai
2026-06-01 22:18 ` [PATCH bpf-next v1 10/14] selftests/bpf: Verify bpf_fastcall decl tags in resolve_btfids test Ihor Solodrai
2026-06-03 23:47   ` Andrii Nakryiko
2026-06-01 22:18 ` [PATCH bpf-next v1 11/14] resolve_btfids: Process KF_ARENA_* flags in resolve_btfids Ihor Solodrai
2026-06-03 23:47   ` Andrii Nakryiko
2026-06-01 22:18 ` [PATCH bpf-next v1 12/14] selftests/bpf: Verify arena type tags in resolve_btfids test Ihor Solodrai
2026-06-01 22:29   ` sashiko-bot
2026-06-03 23:46   ` Andrii Nakryiko
2026-06-01 22:18 ` [PATCH bpf-next v1 13/14] kbuild: Drop decl_tag_kfuncs and attributes from pahole flags Ihor Solodrai
2026-06-03 23:48   ` Andrii Nakryiko
2026-06-01 22:18 ` [PATCH bpf-next v1 14/14] docs, resolve_btfids: Document kfunc BTF annotation emission Ihor Solodrai
2026-06-03 23:45 ` [PATCH bpf-next v1 00/14] resolve_btfids: Implement BTF tags emission for kfuncs Andrii Nakryiko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260601222857.DFAB11F00893@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=ihor.solodrai@linux.dev \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.