From: sashiko-bot@kernel.org
To: "Amery Hung" <ameryhung@gmail.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v1 17/18] bpf: Classify scalar kfunc arguments from BTF
Date: Thu, 23 Jul 2026 08:01:03 +0000 [thread overview]
Message-ID: <20260723080103.AE5CF1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260723050806.1158442-18-ameryhung@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] The `KF_ARG_MEM_SIZE` argument type completely bypasses the `SCALAR_VALUE` check, allowing eBPF programs to pass massive pointers as buffer sizes.
- [Low] Uninitialized variables `ref_t` and `ref_tname` passed by value to `get_kfunc_arg_type()`.
--
--- Patch [17]: [PATCH bpf-next v1 17/18] bpf: Classify scalar kfunc arguments from BTF ---
commit ea739f7fbc71c6a534cb3103ddbdf3b31c5f391a
Author: Amery Hung <ameryhung@gmail.com>
Subject: bpf: Classify scalar kfunc arguments from BTF
This patch updates how scalar kfunc arguments are handled by moving their
classification out of the inline register state validation and into BTF-based
classification. It adds specific KF_ARG_* kinds for scalars and separates
BTF classification from register validation in check_kfunc_args.
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 24858a38c34cf..ba2608592bd5f 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
[ ... ]
> @@ -12130,11 +12122,13 @@ static int check_kfunc_args(struct bpf_verifier_env *env, struct bpf_call_arg_me
> if (reg_is_referenced(env, reg))
> update_ref_obj(&meta->ref_obj, reg);
>
> - ref_t = btf_type_skip_modifiers(btf, t->type, &ref_id);
> - ref_tname = btf_name_by_offset(btf, ref_t->name_off);
> + if (btf_type_is_ptr(t)) {
> + ref_t = btf_type_skip_modifiers(btf, t->type, &ref_id);
> + ref_tname = btf_name_by_offset(btf, ref_t->name_off);
> + }
>
> - kf_arg_type = get_kfunc_ptr_arg_type(env, meta, t, ref_t, ref_tname,
> - args, i, nargs, argno);
> + kf_arg_type = get_kfunc_arg_type(env, meta, t, ref_t, ref_tname,
> + args, i, nargs, argno);
[Severity: Low]
If a kfunc call has a scalar argument, btf_type_is_ptr(t) evaluates to false,
skipping the initialization of ref_t and ref_tname.
Could this result in passing uninitialized variables from the stack by value
into get_kfunc_arg_type() during check_kfunc_args()?
[ ... ]
> @@ -12435,6 +12462,19 @@ static int check_kfunc_args(struct bpf_verifier_env *env, struct bpf_call_arg_me
> }
> }
> break;
> + case KF_ARG_CONST_MEM_SIZE:
> + if (reg->type != SCALAR_VALUE) {
> + verbose(env, "%s is not a scalar\n", reg_arg_name(env, argno));
> + return -EINVAL;
> + }
> +
> + ret = process_const_arg(env, reg, argno, meta);
> + if (ret < 0)
> + return ret;
> +
> + fallthrough;
> + case KF_ARG_MEM_SIZE:
> + break;
[Severity: Critical]
Does this allow an eBPF program to bypass the scalar check by passing a
non-scalar register as the size parameter?
Because the KF_ARG_MEM_SIZE case label is placed after the SCALAR_VALUE
check inside KF_ARG_CONST_MEM_SIZE, an argument that is exactly
KF_ARG_MEM_SIZE will jump directly to its label and break out, leaving the
register's type unchecked.
Could this allow programs to pass a pointer as a buffer size, potentially
leading to out-of-bounds memory accesses?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260723050806.1158442-1-ameryhung@gmail.com?part=17
next prev parent reply other threads:[~2026-07-23 8:01 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-23 5:07 [PATCH bpf-next v1 00/18] Generate bpf_func_proto for kfunc Amery Hung
2026-07-23 5:07 ` [PATCH bpf-next v1 01/18] bpf: Drop process_timer_func wrappers Amery Hung
2026-07-23 5:07 ` [PATCH bpf-next v1 02/18] bpf: Unify const map ptr argument checking for helpers and kfuncs Amery Hung
2026-07-23 5:25 ` sashiko-bot
2026-07-23 5:07 ` [PATCH bpf-next v1 03/18] bpf: Split kfunc map argument into __const_map and __map Amery Hung
2026-07-23 5:35 ` sashiko-bot
2026-07-23 5:07 ` [PATCH bpf-next v1 04/18] bpf: Pass kfunc meta to mem and mem_size check Amery Hung
2026-07-23 5:07 ` [PATCH bpf-next v1 05/18] bpf: Check helper and kfunc mem+size arguments identically Amery Hung
2026-07-23 5:52 ` sashiko-bot
2026-07-23 5:07 ` [PATCH bpf-next v1 06/18] selftests/bpf: Add tests for helper and kfunc mem+size arguments Amery Hung
2026-07-23 5:42 ` sashiko-bot
2026-07-23 5:07 ` [PATCH bpf-next v1 07/18] bpf: Check fixed-size mem args of helpers and kfuncs the same way Amery Hung
2026-07-23 5:57 ` sashiko-bot
2026-07-23 5:07 ` [PATCH bpf-next v1 08/18] bpf: Express ARG_CONST_SIZE_OR_ZERO as ARG_CONST_SIZE | SCALAR_MAYBE_ZERO Amery Hung
2026-07-23 5:07 ` [PATCH bpf-next v1 09/18] bpf: Rename ARG_CONST_SIZE{,_OR_ZERO} to ARG_MEM_SIZE{,_OR_ZERO} Amery Hung
2026-07-23 5:07 ` [PATCH bpf-next v1 10/18] bpf: Fold __szk const size handling into the scalar arg path Amery Hung
2026-07-23 5:07 ` [PATCH bpf-next v1 11/18] bpf: Classify kfunc mem_size args from BTF without register state Amery Hung
2026-07-23 5:08 ` [PATCH bpf-next v1 12/18] bpf: Handle NULL kfunc pointer args without a KF_ARG_PTR_TO_NULL type Amery Hung
2026-07-23 5:08 ` [PATCH bpf-next v1 13/18] bpf: Distinguish fixed- and variable-size kfunc mem args with MEM_FIXED_SIZE Amery Hung
2026-07-23 5:08 ` [PATCH bpf-next v1 14/18] bpf: Check helper mem+size in ARG_PTR_TO_MEM case Amery Hung
2026-07-23 5:08 ` [PATCH bpf-next v1 15/18] bpf: Classify kfunc pointer arguments from BTF, resolve type against the register Amery Hung
2026-07-23 7:27 ` sashiko-bot
2026-07-23 5:08 ` [PATCH bpf-next v1 16/18] bpf: Tag nullable kfunc pointer args with PTR_MAYBE_NULL Amery Hung
2026-07-23 5:08 ` [PATCH bpf-next v1 17/18] bpf: Classify scalar kfunc arguments from BTF Amery Hung
2026-07-23 8:01 ` sashiko-bot [this message]
2026-07-23 5:08 ` [PATCH bpf-next v1 18/18] bpf: Generate kfunc argument prototype at add-call time Amery Hung
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=20260723080103.AE5CF1F000E9@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.