From: sashiko-bot@kernel.org
To: "Amery Hung" <ameryhung@gmail.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v1 07/18] bpf: Check fixed-size mem args of helpers and kfuncs the same way
Date: Thu, 23 Jul 2026 05:57:58 +0000 [thread overview]
Message-ID: <20260723055758.5F7201F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260723050806.1158442-8-ameryhung@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Global subprograms incorrectly accept NULL pointers for non-nullable ARG_PTR_TO_MEM arguments, leading to kernel NULL pointer dereference.
--
--- Patch [7]: [PATCH bpf-next v1 07/18] bpf: Check fixed-size mem args of helpers and kfuncs the same way ---
commit 878ed5f4f87b10a9bf04aa450c46f6f99550d430
Author: Amery Hung <ameryhung@gmail.com>
bpf: Check fixed-size mem args of helpers and kfuncs the same way
This commit consolidates the fixed-size memory argument checking for helpers,
kfuncs, and global subprograms by routing the helper MEM_FIXED_SIZE case
through check_mem_reg. It also resolves a bug where passing a NULL to an
argument marked PTR_MAYBE_NULL | ARG_PTR_TO_FIXED_SIZE_MEM would falsely
reject the program.
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 6520742d51b58..be5d93c0da813 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -6941,11 +6941,14 @@ static int check_mem_size_reg(struct bpf_verifier_env *env,
> }
>
> static int check_mem_reg(struct bpf_verifier_env *env, struct bpf_reg_state *reg,
> - argno_t argno, u32 mem_size, struct bpf_call_arg_meta *meta)
> + argno_t argno, u32 mem_size, enum bpf_access_type access_type,
> + struct bpf_call_arg_meta *meta)
> {
> + /* meta->btf is set only for kfuncs; a NULL meta means a global subprog. */
> + bool helper = meta && !meta->btf;
> bool may_be_null = type_may_be_null(reg->type);
> struct bpf_reg_state saved_reg;
> - int err;
> + int size, err = 0;
>
> if (bpf_register_is_null(reg))
> return 0;
[Severity: High]
This isn't a bug introduced by this patch, but does this early return allow a
NULL pointer to bypass memory access bounds checks and type validations when
the register is a constant 0?
[ ... ]
> @@ -9257,7 +9261,7 @@ static int btf_check_func_arg_match(struct bpf_verifier_env *env, int subprog,
> ret = check_func_arg_reg_off(env, reg, argno, ARG_DONTCARE);
> if (ret < 0)
> return ret;
> - if (check_mem_reg(env, reg, argno, arg->mem_size, NULL))
> + if (check_mem_reg(env, reg, argno, arg->mem_size, BPF_READ | BPF_WRITE, NULL))
> return -EINVAL;
> if (!(arg->arg_type & PTR_MAYBE_NULL) && (reg->type & PTR_MAYBE_NULL)) {
> bpf_log(log, "%s is expected to be non-NULL\n",
[Severity: High]
This is a pre-existing issue, but if a caller passes a hardcoded NULL
(SCALAR_VALUE of 0) to a global subprogram expecting a non-nullable
ARG_PTR_TO_MEM, check_mem_reg returns 0 immediately.
Because the SCALAR_VALUE type does not have the PTR_MAYBE_NULL flag set,
this subsequent bitwise check in btf_check_func_arg_match:
!(arg->arg_type & PTR_MAYBE_NULL) && (reg->type & PTR_MAYBE_NULL)
will fail to catch the NULL. Could this allow a global subprogram to
incorrectly accept and dereference a NULL pointer at runtime, resulting
in a kernel panic?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260723050806.1158442-1-ameryhung@gmail.com?part=7
next prev parent reply other threads:[~2026-07-23 5:57 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 [this message]
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
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=20260723055758.5F7201F000E9@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.