linux-kernel - Re: [PATCH bpf-next v2 05/13] resolve_btfids: Support for KF_IMPLICIT

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <b15c25ab-2475-4129-bebe-db0c2f3a6aa8@linux.dev>
Date: Fri, 16 Jan 2026 12:44:34 -0800
From: Ihor Solodrai <ihor.solodrai@...ux.dev>
To: bot+bpf-ci@...nel.org, ast@...nel.org, daniel@...earbox.net,
 andrii@...nel.org, martin.lau@...ux.dev, eddyz87@...il.com
Cc: yatsenko@...a.com, tj@...nel.org, alan.maguire@...cle.com,
 bentiss@...nel.org, jikos@...nel.org, ameryhung@...il.com,
 bpf@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-input@...r.kernel.org, sched-ext@...ts.linux.dev,
 martin.lau@...nel.org, yonghong.song@...ux.dev, clm@...a.com
Subject: Re: [PATCH bpf-next v2 05/13] resolve_btfids: Support for
 KF_IMPLICIT_ARGS

On 1/16/26 12:39 PM, bot+bpf-ci@...nel.org wrote:
>> diff --git a/tools/bpf/resolve_btfids/main.c b/tools/bpf/resolve_btfids/main.c
>> index 1fcf37af6764..b83316359cfd 100644
>> --- a/tools/bpf/resolve_btfids/main.c
>> +++ b/tools/bpf/resolve_btfids/main.c
> 
> [ ... ]
> 
>> +struct btf2btf_context {
>> +	struct btf *btf;
>> +	u32 *decl_tags;
>> +	u32 nr_decl_tags;
>> +	struct kfunc *kfuncs;
>> +	u32 nr_kfuncs;
>> +};
> 
> [ ... ]
> 
>> +static int collect_decl_tags(struct btf2btf_context *ctx)
>> +{
>> +	const u32 type_cnt = btf__type_cnt(ctx->btf);
>> +	struct btf *btf = ctx->btf;
>> +	const struct btf_type *t;
>> +	u32 *tags, *tmp;
>> +	u32 nr_tags = 0;
>> +
>> +	tags = malloc(type_cnt * sizeof(u32));
>> +	if (!tags)
>> +		return -ENOMEM;
> 
> [ ... ]
> 
>> +	tmp = realloc(tags, nr_tags * sizeof(u32));
>> +	if (!tmp) {
>> +		free(tags);
>> +		return -ENOMEM;
>> +	}
>> +
>> +	ctx->decl_tags = tmp;
>> +	ctx->nr_decl_tags = nr_tags;
>> +
>> +	return 0;
>> +}
> 
> [ ... ]
> 
>> +static s64 collect_kfuncs(struct object *obj, struct btf2btf_context *ctx)
>> +{
>> +	struct kfunc *kfunc, *kfuncs, *tmp;
> 
> [ ... ]
> 
>> +	kfuncs = malloc(ctx->nr_decl_tags * sizeof(*kfuncs));
>> +	if (!kfuncs)
>> +		return -ENOMEM;
> 
> [ ... ]
> 
>> +	tmp = realloc(kfuncs, nr_kfuncs * sizeof(*kfuncs));
>> +	if (!tmp) {
>> +		free(kfuncs);
>> +		return -ENOMEM;
>> +	}
>> +
>> +	ctx->kfuncs = tmp;
>> +	ctx->nr_kfuncs = nr_kfuncs;
>> +
>> +	return 0;
>> +}
>> +
>> +static int build_btf2btf_context(struct object *obj, struct btf2btf_context *ctx)
>> +{
>> +	int err;
>> +
>> +	ctx->btf = obj->btf;
>> +
>> +	err = collect_decl_tags(ctx);
>> +	if (err) {
>> +		pr_err("ERROR: resolve_btfids: failed to collect decl tags from BTF\n");
>> +		return err;
>> +	}
>> +
>> +	err = collect_kfuncs(obj, ctx);
>> +	if (err) {
>> +		pr_err("ERROR: resolve_btfids: failed to collect kfuncs from BTF\n");
>> +		return err;
>                   ^^^^
> 
> When collect_kfuncs() fails here, ctx->decl_tags has already been allocated
> by collect_decl_tags() but is not freed before returning. Should this error
> path call free(ctx->decl_tags)?
> 
>> +	}
>> +
>> +	return 0;
>> +}
> 
> [ ... ]
> 
>> +static int btf2btf(struct object *obj)
>> +{
>> +	struct btf2btf_context ctx = {};
>> +	int err;
>> +
>> +	err = build_btf2btf_context(obj, &ctx);
>> +	if (err)
>> +		return err;
>> +
>> +	for (u32 i = 0; i < ctx.nr_kfuncs; i++) {
>> +		struct kfunc *kfunc = &ctx.kfuncs[i];
>> +
>> +		if (!(kfunc->flags & KF_IMPLICIT_ARGS))
>> +			continue;
>> +
>> +		err = process_kfunc_with_implicit_args(&ctx, kfunc);
>> +		if (err)
>> +			return err;
>> +	}
>> +
>> +	return 0;
>> +}
>           ^^^^
> 
> ctx.decl_tags and ctx.kfuncs are allocated during build_btf2btf_context()
> but are never freed on any return path from btf2btf(). While this may be
> acceptable for a short-lived build tool where the OS reclaims memory on
> exit, should cleanup be added for consistency with the rest of the code
> which carefully frees allocations?

Right. I just noticed this after sending.

As AI mentioned, it's not a sever issue, but we should free everything
properly to be consistent.


> 
> 
> ---
> AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
> See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
> 
> CI run summary: https://github.com/kernel-patches/bpf/actions/runs/21079944982