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: [RFC PATCH bpf-next v1 04/16] bpf: Add the typed_arena_cast instruction
Date: Sat, 26 Sep 2026 23:55:41 +0000	[thread overview]
Message-ID: <20260926235541.CFF5B1F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260926233503.3114147-5-memxor@gmail.com>

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] bpf: typed arenas leak on late verification failure
- [Medium] bpf: diagnostic log state leak in check_alu_op() on typed arena cast
- [Low] bpf: comment style violation in backtrack_insn()
--

commit 1039fff673a440b6fdcfc452a1630f899213bc0c
Author: Kumar Kartikeya Dwivedi <memxor@gmail.com>

bpf: Add the typed_arena_cast instruction

This commit adds the typed_arena_cast instruction, which turns an untrusted
64-bit value into a verifier-trusted pointer to a typed arena object. The
verifier registers the typed arena on first sight, logs it, and lowers the
instruction after verification.

> diff --git a/kernel/bpf/backtrack.c b/kernel/bpf/backtrack.c
> index 0e38b9575328c..38984e52ee375 100644
> --- a/kernel/bpf/backtrack.c
> +++ b/kernel/bpf/backtrack.c
> @@ -328,11 +328,13 @@ static int backtrack_insn(struct bpf_verifier_env *env, int idx, int subseq_idx,
>  				if (sreg != BPF_REG_FP)
>  					bt_set_reg(bt, sreg);
>  			} else {
> -				/* dreg = K
> +				/* dreg = K, or dreg = typed_arena_cast(sreg, imm)
>  				 * dreg needs precision after this insn.
>  				 * Corresponding register is already marked
>  				 * as precise=true in this verifier state.
> -				 * No further markings in parent are necessary
> +				 * No further markings in parent are necessary;
> +				 * a cast yields a pointer that is safe for any
> +				 * value of sreg, which needs no precision.
>  				 */
                                 ^^^

[Severity: Low]
Does this multi-line comment violate the BPF subsystem comment formatting rules?
The opening /* should typically be on its own line for multi-line comments in
BPF subsystem code.

[ ... ]

> diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
> index d3b8b626ec0f7..619f7c6a778d9 100644
> --- a/kernel/bpf/core.c
> +++ b/kernel/bpf/core.c
> @@ -3085,6 +3085,8 @@ static void bpf_prog_free_deferred(struct work_struct *work)
>  	aux = container_of(work, struct bpf_prog_aux, work);
>  #ifdef CONFIG_BPF_SYSCALL
>  	bpf_free_kfunc_btf_tab(aux->kfunc_btf_tab);
> +	/* The typed arenas outlive the program; only the load's failure retracts them. */
> +	kfree(aux->typed_arenas);
>  #endif
>  #ifdef CONFIG_CGROUP_BPF
>  	if (aux->cgroup_atype != CGROUP_BPF_ATTACH_TYPE_INVALID)

[ ... ]

> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 03dbc0e003986..a0069983f1036 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -16993,7 +17173,9 @@ static int check_alu_op(struct bpf_verifier_env *env, struct bpf_insn *insn)
>  			struct bpf_reg_state *dst_reg = regs + insn->dst_reg;
>  
>  			if (BPF_CLASS(insn->code) == BPF_ALU64) {
> -				if (insn->imm) {
> +				if (insn->off == BPF_TYPED_ARENA_CAST) {
> +					return check_typed_arena_cast(env, insn);
                                        ^^^^

[Severity: Medium]
Does this early return bypass the paired bpf_diag_mod_end(env) cleanup at the
end of check_alu_op()? Leaving the diagnostic state active here fails to record
the register modification in the diagnostic event log.

> +				} else if (insn->imm) {
>  					/* off == BPF_ADDR_SPACE_CAST */
>  					mark_reg_unknown(env, regs, insn->dst_reg);
>  					if (insn->imm == 1) /* cast from as(1) to as(0) */

[ ... ]

> @@ -20580,8 +20764,26 @@ static int resolve_func_ptrs(struct bpf_verifier_env *env)
>  }
>  
>  /* drop refcnt of maps used by the rejected program */
> +/*
> + * Drop the rejected program's typed arena references before its arena map
> + * reference. A typed arena nobody else registered is retracted; one that a
> + * loaded program registered lives on for the map's lifetime.
> + */
> +static void release_typed_arenas(struct bpf_verifier_env *env)
> +{
> +	struct bpf_prog_aux *aux = env->prog->aux;
> +	u32 i;
> +
> +	for (i = 0; i < aux->typed_arena_cnt; i++)
> +		bpf_typed_arena_put(bpf_prog_arena(env->prog), aux->typed_arenas[i]);
> +	kfree(aux->typed_arenas);
> +	aux->typed_arenas = NULL;
> +	aux->typed_arena_cnt = 0;
> +}
> +
>  static void release_maps(struct bpf_verifier_env *env)
>  {
> +	release_typed_arenas(env);
        ^^^^

[Severity: High]
Can this leak the typed arena references?

In bpf_check(), if verification fails after env->prog->aux->used_maps is
populated, the err_release_maps path bypasses calling release_maps(env):

err_release_maps:
	if (ret)
		release_insn_arrays(env);
	if (!env->prog->aux->used_maps)
		release_maps(env);

If release_maps(env) is skipped, release_typed_arenas(env) will not be called.
Then, bpf_prog_free_deferred() only does kfree(aux->typed_arenas) without
dropping the actual bpf_typed_arena_put() refcounts, permanently leaking
the typed arenas and their backing resources.

>  	__bpf_free_used_maps(env->prog->aux, env->used_maps,
>  			     env->used_map_cnt);
>  }

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

  reply	other threads:[~2026-09-26 23:55 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-26 23:34 [RFC PATCH bpf-next v1 00/16] BPF typed arenas Kumar Kartikeya Dwivedi
2026-09-26 23:34 ` [RFC PATCH bpf-next v1 01/16] mm/vmalloc: Add get_vm_area_align() Kumar Kartikeya Dwivedi
2026-09-26 23:42   ` sashiko-bot
2026-09-26 23:34 ` [RFC PATCH bpf-next v1 02/16] bpf: Introduce BPF typed arenas Kumar Kartikeya Dwivedi
2026-09-26 23:34 ` [RFC PATCH bpf-next v1 03/16] bpf: Back typed arena chunks with scratch on demand Kumar Kartikeya Dwivedi
2026-09-26 23:56   ` sashiko-bot
2026-09-26 23:34 ` [RFC PATCH bpf-next v1 04/16] bpf: Add the typed_arena_cast instruction Kumar Kartikeya Dwivedi
2026-09-26 23:55   ` sashiko-bot [this message]
2026-09-26 23:34 ` [RFC PATCH bpf-next v1 05/16] bpf: Allow scalar and atomic access to typed arena objects Kumar Kartikeya Dwivedi
2026-09-26 23:34 ` [RFC PATCH bpf-next v1 06/16] bpf: Support special fields in " Kumar Kartikeya Dwivedi
2026-09-26 23:59   ` sashiko-bot
2026-09-26 23:34 ` [RFC PATCH bpf-next v1 07/16] bpf: Trust typed pointer fields of " Kumar Kartikeya Dwivedi
2026-09-27  0:03   ` sashiko-bot
2026-09-26 23:34 ` [RFC PATCH bpf-next v1 08/16] bpf: Canonicalize loaded typed arena pointers where they are used Kumar Kartikeya Dwivedi
2026-09-26 23:34 ` [RFC PATCH bpf-next v1 09/16] bpf: Add typed arena page allocation and release kfuncs Kumar Kartikeya Dwivedi
2026-09-26 23:55   ` sashiko-bot
2026-09-26 23:34 ` [RFC PATCH bpf-next v1 10/16] bpf: Let typed_arena_cast copy pointers the verifier already trusts Kumar Kartikeya Dwivedi
2026-09-26 23:49   ` sashiko-bot
2026-09-26 23:34 ` [RFC PATCH bpf-next v1 11/16] libbpf: Support the typed_arena_cast instruction Kumar Kartikeya Dwivedi
2026-09-26 23:34 ` [RFC PATCH bpf-next v1 12/16] selftests/bpf: Build BPF objects with compiler-inserted typed arena casts Kumar Kartikeya Dwivedi
2026-09-26 23:46   ` sashiko-bot
2026-09-26 23:34 ` [RFC PATCH bpf-next v1 13/16] selftests/bpf: Test typed arena casts and registration Kumar Kartikeya Dwivedi
2026-09-26 23:34 ` [RFC PATCH bpf-next v1 14/16] selftests/bpf: Test typed arena object access, kptrs and typed pointer fields Kumar Kartikeya Dwivedi
2026-09-26 23:34 ` [RFC PATCH bpf-next v1 15/16] selftests/bpf: Test typed arena page allocation and release Kumar Kartikeya Dwivedi
2026-09-26 23:46   ` sashiko-bot
2026-09-26 23:34 ` [RFC PATCH bpf-next v1 16/16] selftests/bpf: Exercise typed arenas at run time Kumar Kartikeya Dwivedi
2026-09-26 23:50   ` sashiko-bot

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=20260926235541.CFF5B1F000FF@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.