All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Amery Hung" <ameryhung@gmail.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v2 11/18] bpf: Classify kfunc mem_size args from BTF without register state
Date: Fri, 24 Jul 2026 19:38:53 +0000	[thread overview]
Message-ID: <20260724193854.57F981F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260724190813.1458271-12-ameryhung@gmail.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Removing the `SCALAR_VALUE` check from `is_kfunc_arg_mem_size()` and `is_kfunc_arg_const_mem_size()` allows unvalidated pointer registers to be passed as memory size arguments during kfunc lookahead validation, triggering a `verifier_bug` kernel warning splat and local DoS.
--

--- Patch [11]: [PATCH bpf-next v2 11/18] bpf: Classify kfunc mem_size args from BTF without register state ---
commit 55013229ec44003dda12328783652d410aa4f75e
Author: Amery Hung <ameryhung@gmail.com>

bpf: Classify kfunc mem_size args from BTF without register state

This commit drops the scalar register type check in is_kfunc_arg_mem_size()
and is_kfunc_arg_const_mem_size() to decouple get_kfunc_ptr_arg_type()
from register state.

> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 0f8d403083177..f6b373630ca95 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -10795,26 +10795,24 @@ static bool is_kfunc_rcu_protected(struct bpf_call_arg_meta *meta)
>  }
>  
>  static bool is_kfunc_arg_mem_size(const struct btf *btf,
> -				  const struct btf_param *arg,
> -				  const struct bpf_reg_state *reg)
> +				  const struct btf_param *arg)
>  {
>  	const struct btf_type *t;
>  
>  	t = btf_type_skip_modifiers(btf, arg->type, NULL);
> -	if (!btf_type_is_scalar(t) || reg->type != SCALAR_VALUE)
> +	if (!btf_type_is_scalar(t))
>  		return false;
>  
>  	return btf_param_match_suffix(btf, arg, "__sz");
>  }

[Severity: High]
Could this removal allow a pointer register to be incorrectly classified as a
memory size parameter during kfunc lookahead validation?

If a BPF program passes a pointer register (such as PTR_TO_STACK with a fixed
offset of 0) instead of a scalar to a size argument suffixed with __sz,
get_kfunc_ptr_arg_type() will now look ahead and classify it solely based on
the BTF signature.

Because of this classification, check_kfunc_args() eagerly processes the
unverified register as a size parameter before the generic scalar validation
loop catches it:

check_kfunc_args()
    ...
    check_mem_size_reg(env, buff_reg, size_reg, argno, next_argno, ...)

Inside check_mem_size_reg(), the pointer with a fixed offset of 0 yields a
size of 0. Since zero-size is allowed, it passes the bounds check and calls
mark_chain_precision() on the pointer register.

Because mark_chain_precision() expects a SCALAR_VALUE, it triggers a
verifier_bug splat for backtracking misuse when given a pointer. On systems
configured with panic_on_warn, this creates a local denial of service
regression.

Should the register type check be retained here, or is there another way to
prevent pointer registers from bypassing validation during the lookahead?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260724190813.1458271-1-ameryhung@gmail.com?part=11

  reply	other threads:[~2026-07-24 19:38 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-24 19:07 [PATCH bpf-next v2 00/18] Generate bpf_func_proto for kfunc Amery Hung
2026-07-24 19:07 ` [PATCH bpf-next v2 01/18] bpf: Drop process_timer_func wrappers Amery Hung
2026-07-25  1:39   ` Eduard Zingerman
2026-07-24 19:07 ` [PATCH bpf-next v2 02/18] bpf: Unify const map ptr argument checking for helpers and kfuncs Amery Hung
2026-07-24 19:28   ` sashiko-bot
2026-07-24 20:49     ` Amery Hung
2026-07-24 21:29       ` Kumar Kartikeya Dwivedi
2026-07-25  1:57   ` Eduard Zingerman
2026-07-24 19:07 ` [PATCH bpf-next v2 03/18] bpf: Split kfunc map argument into __const_map and __map Amery Hung
2026-07-24 19:07 ` [PATCH bpf-next v2 04/18] bpf: Pass kfunc meta to mem and mem_size check Amery Hung
2026-07-24 19:07 ` [PATCH bpf-next v2 05/18] bpf: Check helper and kfunc mem+size arguments identically Amery Hung
2026-07-24 19:08 ` [PATCH bpf-next v2 06/18] selftests/bpf: Add tests for helper and kfunc mem+size arguments Amery Hung
2026-07-24 19:25   ` sashiko-bot
2026-07-24 19:08 ` [PATCH bpf-next v2 07/18] bpf: Check fixed-size mem args of helpers and kfuncs the same way Amery Hung
2026-07-24 19:32   ` sashiko-bot
2026-07-24 20:39     ` Amery Hung
2026-07-24 19:08 ` [PATCH bpf-next v2 08/18] bpf: Express ARG_CONST_SIZE_OR_ZERO as ARG_CONST_SIZE | SCALAR_MAYBE_ZERO Amery Hung
2026-07-24 19:08 ` [PATCH bpf-next v2 09/18] bpf: Rename ARG_CONST_SIZE{,_OR_ZERO} to ARG_MEM_SIZE{,_OR_ZERO} Amery Hung
2026-07-24 19:08 ` [PATCH bpf-next v2 10/18] bpf: Fold __szk const size handling into the scalar arg path Amery Hung
2026-07-24 19:08 ` [PATCH bpf-next v2 11/18] bpf: Classify kfunc mem_size args from BTF without register state Amery Hung
2026-07-24 19:38   ` sashiko-bot [this message]
2026-07-24 22:52     ` Amery Hung
2026-07-24 19:08 ` [PATCH bpf-next v2 12/18] bpf: Handle NULL kfunc pointer args without a KF_ARG_PTR_TO_NULL type Amery Hung
2026-07-24 19:08 ` [PATCH bpf-next v2 13/18] bpf: Distinguish fixed- and variable-size kfunc mem args with MEM_FIXED_SIZE Amery Hung
2026-07-24 19:08 ` [PATCH bpf-next v2 14/18] bpf: Check helper mem+size in ARG_PTR_TO_MEM case Amery Hung
2026-07-24 19:47   ` sashiko-bot
2026-07-24 21:10     ` Amery Hung
2026-07-24 19:08 ` [PATCH bpf-next v2 15/18] bpf: Classify kfunc pointer arguments from BTF, resolve type against the register Amery Hung
2026-07-24 19:08 ` [PATCH bpf-next v2 16/18] bpf: Tag nullable kfunc pointer args with PTR_MAYBE_NULL Amery Hung
2026-07-24 19:38   ` sashiko-bot
2026-07-24 19:08 ` [PATCH bpf-next v2 17/18] bpf: Classify scalar kfunc arguments from BTF Amery Hung
2026-07-24 19:08 ` [PATCH bpf-next v2 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=20260724193854.57F981F000E9@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.