All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Kumar Kartikeya Dwivedi" <memxor@gmail.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v1 05/17] bpf: Track verifier register diagnostic history
Date: Fri, 05 Jun 2026 06:53:01 +0000	[thread overview]
Message-ID: <20260605065301.A27671F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260605063412.974640-6-memxor@gmail.com>

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Excessive stack allocation in diagnostic formatting functions can cause kernel stack overflows.
- [Medium] Uninitialized stack memory read in check_stack_arg_write() due to uninitialized old_arg.
- [Medium] Diagnostic history records incorrect frame numbers for registers invalidated in caller frames.
--

commit 9a17934339f89b801d41d6242f00c9032267ab0f
Author: Kumar Kartikeya Dwivedi <memxor@gmail.com>

bpf: Track verifier register diagnostic history

Record material register and outgoing stack argument changes so diagnostics can
explain how a value reached its current type, bounds, or unreadable state.
Store old and new register types, scalar ranges, tnum value and mask, map and
BTF type identity, and basic operand metadata.

> diff --git a/kernel/bpf/diagnostics.c b/kernel/bpf/diagnostics.c
> index 50cc50a394cae..1bdc7e69fbced 100644
> --- a/kernel/bpf/diagnostics.c
> +++ b/kernel/bpf/diagnostics.c
[ ... ]
> +static void bpf_diag_record_reg_mod_reason(struct bpf_verifier_state *state,
> +					   u32 insn_idx, u8 dst_reg,
> +					   bool src_valid, u8 src_reg,
> +					   u8 opcode,
> +					   enum bpf_diag_reg_mod_reason reason,
> +					   const struct bpf_reg_state *old_reg,
> +					   const struct bpf_reg_state *new_reg)
> +{
> +	struct bpf_diag_history_event event = {
> +		.insn_idx = insn_idx,
> +		.kind = BPF_DIAG_HISTORY_REG_MOD,
> +		.reg.dst_reg = dst_reg,
> +		.reg.src_reg = src_reg,
> +		.reg.opcode = opcode,
> +		.reg.src_valid = src_valid,
> +	};
> +
> +	if (state && state->frame[state->curframe])
> +		event.reg.frameno = state->frame[state->curframe]->frameno;

[Severity: Medium]
Will this record the wrong frame number for registers invalidated in caller
frames?

Functions like clear_all_pkt_pointers() and release_reference() iterate over
all active frames to invalidate registers, but this assignment hardcodes the
current executing frame number via state->curframe.

Should bpf_diag_record_reg_mod_reason() accept the actual frame number of the
register from the caller instead?

[ ... ]
> +static void bpf_diag_format_reg_snapshot(struct bpf_verifier_env *env, char *buf,
> +					 size_t size,
> +					 const struct bpf_diag_reg_snapshot *snapshot)
> +{
> +	const char *type_name = reg_type_str(env, snapshot->type);
> +	char offset_desc[BPF_DIAG_REG_DESC_LEN];
> +	char btf_type[BPF_DIAG_REG_DESC_LEN];

[Severity: High]
Could this cause a kernel stack overflow?

BPF_DIAG_REG_DESC_LEN is 512 bytes. This function allocates 1KB on the stack,
and is called by bpf_diag_print_reg_mod() which also allocates 1KB.

Additionally, this function calls bpf_diag_format_var_offset() which
allocates another 512 bytes. This >3KB stack usage chain might trigger
CONFIG_FRAME_WARN build failures or cause panics on architectures with 8KB
stacks.

[ ... ]
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index d60e1309957a7..188201d48108c 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -4033,6 +4033,8 @@ static int check_stack_arg_write(struct bpf_verifier_env *env, struct bpf_func_s
>  	struct bpf_subprog_info *subprog = &env->subprog_info[state->subprogno];
>  	int spi = -off / BPF_REG_SIZE - 1;
>  	struct bpf_reg_state *arg;
> +	struct bpf_reg_state old_arg;
> +	bool slot_exists;
>  	int err;
>  
>  	if (spi >= max_stack_arg_regs) {
> @@ -4041,6 +4043,7 @@ static int check_stack_arg_write(struct bpf_verifier_env *env, struct bpf_func_s
>  		return -EINVAL;
>  	}
>  
> +	slot_exists = spi < state->out_stack_arg_cnt;
>  	err = grow_stack_arg_slots(env, state, spi + 1);
>  	if (err)
>  		return err;
> @@ -4049,13 +4052,27 @@ static int check_stack_arg_write(struct bpf_verifier_env *env, struct bpf_func_s
>  	if (spi + 1 > subprog->max_out_stack_arg_cnt)
>  		subprog->max_out_stack_arg_cnt = spi + 1;
>  
> +	arg = &state->stack_arg_regs[spi];
> +	if (slot_exists)
> +		old_arg = *arg;
> +	else
> +		bpf_mark_reg_not_init(env, &old_arg);

[Severity: Medium]
Does this pass uninitialized stack memory to bpf_mark_reg_not_init()?

When slot_exists is false, old_arg is declared without initialization.
bpf_mark_reg_not_init() explicitly reads reg->subreg_def into a local
variable before clearing the struct, which could trigger a KMSAN
use-of-uninitialized-value warning.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260605063412.974640-1-memxor@gmail.com?part=5

  reply	other threads:[~2026-06-05  6:53 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-05  6:33 [PATCH bpf-next v1 00/17] Redesign Verification Errors Kumar Kartikeya Dwivedi
2026-06-05  6:33 ` [PATCH bpf-next v1 01/17] bpf: Add verifier diagnostics report helpers Kumar Kartikeya Dwivedi
2026-06-05  6:42   ` sashiko-bot
2026-06-05  7:40   ` bot+bpf-ci
2026-06-05 18:58   ` Eduard Zingerman
2026-06-05  6:33 ` [PATCH bpf-next v1 02/17] bpf: Define verifier diagnostic categories Kumar Kartikeya Dwivedi
2026-06-05 19:10   ` Eduard Zingerman
2026-06-05  6:33 ` [PATCH bpf-next v1 03/17] bpf: Add source and instruction diagnostic context Kumar Kartikeya Dwivedi
2026-06-05  8:48   ` sashiko-bot
2026-06-05 20:22   ` Eduard Zingerman
2026-06-05 20:55     ` Kumar Kartikeya Dwivedi
2026-06-05 21:07       ` Eduard Zingerman
2026-06-05  6:33 ` [PATCH bpf-next v1 04/17] bpf: Track verifier branch diagnostic history Kumar Kartikeya Dwivedi
2026-06-05  6:50   ` sashiko-bot
2026-06-05  7:57   ` bot+bpf-ci
2026-06-05 21:41     ` Eduard Zingerman
2026-06-05 21:37   ` Eduard Zingerman
2026-06-05  6:33 ` [PATCH bpf-next v1 05/17] bpf: Track verifier register " Kumar Kartikeya Dwivedi
2026-06-05  6:53   ` sashiko-bot [this message]
2026-06-05  7:40   ` bot+bpf-ci
2026-06-05 22:31   ` Eduard Zingerman
2026-06-05  6:33 ` [PATCH bpf-next v1 06/17] bpf: Track verifier reference " Kumar Kartikeya Dwivedi
2026-06-05  6:33 ` [PATCH bpf-next v1 07/17] bpf: Track verifier context " Kumar Kartikeya Dwivedi
2026-06-05  6:46   ` sashiko-bot
2026-06-05  7:22   ` bot+bpf-ci
2026-06-05  6:33 ` [PATCH bpf-next v1 08/17] bpf: Report Register Type Safety errors Kumar Kartikeya Dwivedi
2026-06-05  6:57   ` sashiko-bot
2026-06-05  7:23   ` bot+bpf-ci
2026-06-05  6:33 ` [PATCH bpf-next v1 09/17] bpf: Report Memory Safety bounds errors Kumar Kartikeya Dwivedi
2026-06-05  6:45   ` sashiko-bot
2026-06-05  7:57   ` bot+bpf-ci
2026-06-05  6:34 ` [PATCH bpf-next v1 10/17] bpf: Report Resource Lifetime reference leaks Kumar Kartikeya Dwivedi
2026-06-05  6:45   ` sashiko-bot
2026-06-05  7:22   ` bot+bpf-ci
2026-06-05  6:34 ` [PATCH bpf-next v1 11/17] bpf: Report Call Type Safety argument errors Kumar Kartikeya Dwivedi
2026-06-05  6:47   ` sashiko-bot
2026-06-05  7:23   ` bot+bpf-ci
2026-06-05  6:34 ` [PATCH bpf-next v1 12/17] bpf: Report Execution Context Safety errors Kumar Kartikeya Dwivedi
2026-06-05  6:46   ` sashiko-bot
2026-06-05  7:23   ` bot+bpf-ci
2026-06-05  6:34 ` [PATCH bpf-next v1 13/17] bpf: Report Program Structure CFG errors Kumar Kartikeya Dwivedi
2026-06-05  6:51   ` sashiko-bot
2026-06-05  7:22   ` bot+bpf-ci
2026-06-05  6:34 ` [PATCH bpf-next v1 14/17] bpf: Report Policy helper and kfunc errors Kumar Kartikeya Dwivedi
2026-06-05  7:02   ` sashiko-bot
2026-06-05  6:34 ` [PATCH bpf-next v1 15/17] bpf: Report Verifier Limit errors Kumar Kartikeya Dwivedi
2026-06-05  6:53   ` sashiko-bot
2026-06-05  7:40   ` bot+bpf-ci
2026-06-05  6:34 ` [PATCH bpf-next v1 16/17] bpf: Report Verifier Internal errors Kumar Kartikeya Dwivedi
2026-06-05  6:34 ` [PATCH bpf-next v1 17/17] bpf: Gate verifier diagnostics on log level Kumar Kartikeya Dwivedi
2026-06-05  6:58   ` sashiko-bot
2026-06-05  7:40   ` bot+bpf-ci

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=20260605065301.A27671F00893@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=memxor@gmail.com \
    --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.