From: sashiko-bot@kernel.org
To: "Amery Hung" <ameryhung@gmail.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v1 4/4] bpf: Unify helper and kfunc call argument meta
Date: Thu, 09 Jul 2026 23:16:14 +0000 [thread overview]
Message-ID: <20260709231615.0519D1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260709230242.2003459-5-ameryhung@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Uninitialized stack memory read in `check_kfunc_call` when handling kfunc calls in signed BPF programs.
--
--- Patch [4]: [PATCH bpf-next v1 4/4] bpf: Unify helper and kfunc call argument meta ---
commit b1105689a4b2bf6e2532e6d414d410ef55c0694b
Author: Amery Hung <ameryhung@gmail.com>
bpf: Unify helper and kfunc call argument meta
Helper and kfunc argument checking carried two separate meta structs: the
verifier-local struct bpf_call_arg_meta and bpf_kfunc_call_arg_meta.
Merge them into a single struct bpf_call_arg_meta. This is groundwork for
sharing argument checking between helpers and kfuncs.
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index fcd9715eff017..5ccb00a8c84ce 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
[ ... ]
> @@ -12972,7 +12953,7 @@ static int check_kfunc_call(struct bpf_verifier_env *env, struct bpf_insn *insn,
> struct bpf_reg_state *regs = cur_regs(env);
> const char *func_name, *ptr_type_name;
> const struct btf_type *t, *ptr_type;
> - struct bpf_kfunc_call_arg_meta meta;
> + struct bpf_call_arg_meta meta;
> struct bpf_insn_aux_data *insn_aux;
> int err, insn_idx = *insn_idx_p;
> const struct btf_param *args;
[Severity: High]
This is a pre-existing issue, but does this lead to reading an uninitialized
pointer if bpf_fetch_kfunc_arg_meta() returns early?
In check_kfunc_call() in kernel/bpf/verifier.c, the local variable meta is
declared without initialization and passed to bpf_fetch_kfunc_arg_meta().
If the call to fetch_kfunc_meta() inside it returns an error like -EACCES,
it returns early before initializing meta:
kernel/bpf/verifier.c:bpf_fetch_kfunc_arg_meta() {
struct bpf_kfunc_meta kfunc;
int err;
err = fetch_kfunc_meta(env, func_id, offset, &kfunc);
if (err)
return err;
...
}
Back in check_kfunc_call(), the error path evaluates meta.func_name:
err = bpf_fetch_kfunc_arg_meta(env, insn->imm, insn->off, &meta);
if (err == -EACCES && meta.func_name)
verbose(env, "calling kernel function %s is not allowed\n", meta.func_name);
If the stack memory is uninitialized, could meta.func_name contain a garbage
pointer that leads to a crash or an info leak when dereferenced by vsnprintf
during the verbose() call?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260709230242.2003459-1-ameryhung@gmail.com?part=4
next prev parent reply other threads:[~2026-07-09 23:16 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-09 23:02 [PATCH bpf-next v1 0/4] Unify helper and kfunc call_arg_meta Amery Hung
2026-07-09 23:02 ` [PATCH bpf-next v1 1/4] bpf: Remove dynptr check in check_stack_range_initialized() Amery Hung
2026-07-13 23:41 ` Eduard Zingerman
2026-07-09 23:02 ` [PATCH bpf-next v1 2/4] bpf: Factor out raw_mode-related fields in bpf_call_arg_meta Amery Hung
2026-07-09 23:17 ` sashiko-bot
2026-07-09 23:36 ` Amery Hung
2026-07-14 0:08 ` Eduard Zingerman
2026-07-14 23:22 ` Amery Hung
2026-07-09 23:02 ` [PATCH bpf-next v1 3/4] bpf: Unify helper and kfunc allocation-size argument handling Amery Hung
2026-07-10 0:02 ` bot+bpf-ci
2026-07-14 18:14 ` Eduard Zingerman
2026-07-09 23:02 ` [PATCH bpf-next v1 4/4] bpf: Unify helper and kfunc call argument meta Amery Hung
2026-07-09 23:16 ` sashiko-bot [this message]
2026-07-09 23:44 ` Amery Hung
2026-07-14 18:48 ` Eduard Zingerman
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=20260709231615.0519D1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=ameryhung@gmail.com \
--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 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.