From: sashiko-bot@kernel.org
To: "Aelin Reidel" <aelin@mainlining.org>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH v2] resolve_btfids: preserve tag and parameter names when processing implicit args
Date: Fri, 19 Jun 2026 23:02:03 +0000 [thread overview]
Message-ID: <20260619230203.70E7F1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260620-resolve-btfids-implicit-args-use-after-free-v2-1-4132e1f639f0@mainlining.org>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Missing memory allocation check for `tmp_tag_name` leads to undefined behavior on OOM.
- [Medium] `strdup()` on potentially NULL `param_name` introduces a new crash vector on malformed BTF.
--
commit 6cb93b6d37df26aabf2d6e25d7969724248ceefb
Author: Aelin Reidel <aelin@mainlining.org>
resolve_btfids: preserve tag and parameter names when processing implicit args
This commit updates process_kfunc_with_implicit_args() to duplicate
tag and parameter strings before modifying the BTF object. This prevents
btf__add_* operations from dereferencing stale pointers if the internal
BTF storage is grown and reallocated during processing.
> diff --git a/tools/bpf/resolve_btfids/main.c b/tools/bpf/resolve_btfids/main.c
> index f8a91fa7584f4..94b89e9c942ee 100644
> --- a/tools/bpf/resolve_btfids/main.c
> +++ b/tools/bpf/resolve_btfids/main.c
> @@ -1163,18 +1164,22 @@ static int process_kfunc_with_implicit_args(struct btf2btf_context *ctx, struct
> if (strcmp(tag_name, "bpf_kfunc") == 0)
> continue;
>
> + tmp_tag_name = strdup(tag_name);
> idx = btf_decl_tag(t)->component_idx;
>
> if (btf_kflag(t))
> - err = btf__add_decl_attr(btf, tag_name, new_func_id, idx);
> + err = btf__add_decl_attr(btf, tmp_tag_name, new_func_id, idx);
> else
> - err = btf__add_decl_tag(btf, tag_name, new_func_id, idx);
> + err = btf__add_decl_tag(btf, tmp_tag_name, new_func_id, idx);
>
> if (err < 0) {
> pr_err("ERROR: resolve_btfids: failed to add decl tag %s for %s\n",
> - tag_name, tmp_name);
> + tmp_tag_name, tmp_name);
[Severity: Medium]
What happens if strdup() fails and tmp_tag_name is NULL?
If tmp_tag_name is NULL, btf__add_decl_tag() or btf__add_decl_attr() will
fail and return -EINVAL. The error path then blindly passes the NULL
tmp_tag_name to pr_err() using the %s format specifier.
Could this cause a segmentation fault in libc instead of exiting with a
clean error?
> + free(tmp_tag_name);
> return -EINVAL;
> }
> +
> + free(tmp_tag_name);
> }
>
> add_new_proto:
> @@ -1193,12 +1198,17 @@ static int process_kfunc_with_implicit_args(struct btf2btf_context *ctx, struct
> if (is_kf_implicit_arg(btf, ¶ms[i]))
> break;
> param_name = btf__name_by_offset(btf, params[i].name_off);
> - err = btf__add_func_param(btf, param_name, params[i].type);
> + tmp_param_name = strdup(param_name);
[Severity: Medium]
Can param_name be NULL here if the BTF input is malformed and the string
offset is out of bounds?
If btf__name_by_offset() returns NULL, wouldn't strdup() dereference the
NULL pointer and crash?
Prior to this patch, the potentially NULL pointer was safely passed
directly to btf__add_func_param(), which handles NULL by defaulting to an
anonymous parameter.
> + if (!tmp_param_name)
> + return -ENOMEM;
> + err = btf__add_func_param(btf, tmp_param_name, params[i].type);
> if (err < 0) {
> pr_err("ERROR: resolve_btfids: failed to add param %s for %s\n",
> - param_name, kfunc->name);
> + tmp_param_name, kfunc->name);
> + free(tmp_param_name);
> return err;
> }
> + free(tmp_param_name);
> t = (struct btf_type *)btf__type_by_id(btf, proto_id);
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260620-resolve-btfids-implicit-args-use-after-free-v2-1-4132e1f639f0@mainlining.org?part=1
next prev parent reply other threads:[~2026-06-19 23:02 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-19 22:49 [PATCH v2] resolve_btfids: preserve tag and parameter names when processing implicit args Aelin Reidel
2026-06-19 23:02 ` sashiko-bot [this message]
2026-06-19 23:48 ` bot+bpf-ci
2026-06-26 5:26 ` Ihor Solodrai
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=20260619230203.70E7F1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=aelin@mainlining.org \
--cc=bpf@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox