BPF List
 help / color / mirror / Atom feed
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, &params[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

  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