All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Emil Tsalapatis" <emil@etsalapatis.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v3 3/6] bpf: Allow subprogs to return arena pointers
Date: Tue, 02 Jun 2026 01:20:37 +0000	[thread overview]
Message-ID: <20260602012037.E2D961F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260602004120.17087-4-emil@etsalapatis.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The verifier incorrectly marks the return value of global subprograms returning arena pointers as `SCALAR_VALUE` in the caller's state, preventing native pointer use.
--

commit 3756bfe1c313ae3bcfb27afcfb3650b07638ef91
Author: Emil Tsalapatis <emil@etsalapatis.com>

bpf: Allow subprogs to return arena pointers

This commit expands the verifier to permit returning an arena pointer to the
caller from a subprogram. It updates btf_validate_return_type and
check_global_subprog_return_code to allow subprograms to return PTR_TO_ARENA
without failing their own verification.

> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 3a270bc485c20..9dac790905b63 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -16651,6 +16651,10 @@ static int check_global_subprog_return_code(struct bpf_verifier_env *env)
>  	if (err)
>  		return err;
>  
> +	/* Pointers to arena are safe to pass between subprograms. */
> +	if (is_arena_reg(env, BPF_REG_0))
> +		return 0;
> +

[Severity: Medium]
Will this change be sufficient for the caller to actually receive a
PTR_TO_ARENA?

Looking at the caller-side logic in check_func_call(), it appears BPF_REG_0
is still unconditionally marked as a SCALAR_VALUE for all non-void global
subprograms:

kernel/bpf/verifier.c:check_func_call() {
    ...
		/* All non-void global functions return a 64-bit SCALAR_VALUE. */
		if (!subprog_returns_void(env, subprog)) {
			mark_reg_unknown(env, caller->regs, BPF_REG_0);
			caller->regs[BPF_REG_0].subreg_def = DEF_NOT_SUBREG;
		}
    ...
}

Could this cause the caller to receive a scalar instead of the intended arena
pointer, leading the verifier to reject subsequent dereferences with an
invalid mem access error?

>  	if (is_pointer_value(env, BPF_REG_0)) {
>  		verbose(env, "R%d leaks addr as return value\n", BPF_REG_0);
>  		return -EACCES;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260602004120.17087-1-emil@etsalapatis.com?part=3

  reply	other threads:[~2026-06-02  1:20 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-02  0:41 [PATCH bpf-next v3 0/6] Minimize annotations for arena programs Emil Tsalapatis
2026-06-02  0:41 ` [PATCH bpf-next v3 1/6] selftests/bpf: libarena: Add "arena" BTF type tag to __arena qualifier Emil Tsalapatis
2026-06-02  0:41 ` [PATCH bpf-next v3 2/6] verifier: parse BTF type tags for function arguments Emil Tsalapatis
2026-06-02  1:05   ` sashiko-bot
2026-06-02  1:05     ` Emil Tsalapatis
2026-06-02  1:26   ` bot+bpf-ci
2026-06-02  0:41 ` [PATCH bpf-next v3 3/6] bpf: Allow subprogs to return arena pointers Emil Tsalapatis
2026-06-02  1:20   ` sashiko-bot [this message]
2026-06-02  0:41 ` [PATCH bpf-next v3 4/6] selftests/bpf: Remove __arg_arena from the codebase Emil Tsalapatis
2026-06-02  1:31   ` sashiko-bot
2026-06-02  0:41 ` [PATCH bpf-next v3 5/6] selftests/bpf: libarena: Directly return arena pointers from functions Emil Tsalapatis
2026-06-02  1:45   ` sashiko-bot
2026-06-02  0:41 ` [PATCH bpf-next v3 6/6] selftests/bpf: Add tests for the new type-tag based __arena identifier Emil Tsalapatis
2026-06-02  2:00 ` [PATCH bpf-next v3 0/6] Minimize annotations for arena programs patchwork-bot+netdevbpf

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=20260602012037.E2D961F00893@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=emil@etsalapatis.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.