BPF List
 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 v2 2/5] verifier: parse BTF type tags for function arguments
Date: Sat, 30 May 2026 00:59:21 +0000	[thread overview]
Message-ID: <20260530005922.90CEE1F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260530002259.4505-3-emil@etsalapatis.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] btf_scan_type_tags incorrectly rejects valid BPF programs containing unrecognized type tags (e.g., __user, __rcu) by returning -EOPNOTSUPP.
- [High] btf_scan_type_tags fails to discover valid type tags if they are separated from the pointer by other BTF modifiers (like CONST, VOLATILE, or TYPEDEF).
--

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

verifier: parse BTF type tags for function arguments

This patch extracts BTF decl tag parsing into a new function and
introduces type tag parsing for function arguments, specifically
looking for the arena type tag on pointers.

> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
> index 17d4ab0a82068..c6a930aca67ec 100644
> --- a/kernel/bpf/btf.c
> +++ b/kernel/bpf/btf.c

[ ... ]

> +static int btf_scan_type_tags(struct bpf_verifier_env *env,
> +			      const struct btf *btf, u32 type_id,
> +			      u32 *tags)
> +{
> +	const struct btf_type *t;
> +
> +	/* Find the first pointer type in the chain. */
> +	t = btf_type_skip_modifiers(btf, type_id, NULL);
> +	if (!t || !btf_type_is_ptr(t))
> +		return 0;
> +
> +	/* We got a pointer, get all associated type tags. */
> +	t = btf_type_by_id(btf, t->type);
> +	while (t && btf_type_is_type_tag(t)) {

[Severity: High]
Does this loop terminate prematurely if the type tag is preceded by other
modifiers like CONST, VOLATILE, or TYPEDEF?

If the target type of the pointer is structured as:
PTR -> CONST -> TYPE_TAG("arena") -> INT

It appears btf_type_is_type_tag(t) would evaluate to false at the CONST
modifier, causing the loop to exit and valid arena tags to be missed
entirely.

> +		const char *tag = __btf_name_by_offset(btf, t->name_off);
> +
> +		if (strcmp(tag, "arena") == 0) {
> +			*tags |= ARG_TAG_ARENA;
> +		} else {
> +			bpf_log(&env->log, "function signature member has unsupported type tag '%s'\n",
> +				tag);
> +			return -EOPNOTSUPP;
> +		}

[Severity: High]
Will this unconditionally reject valid BPF programs that contain
unrecognized type tags like __user or __rcu?

Prior to this change, standard kernel type tags on pointer arguments were
naturally skipped by the verifier. Returning -EOPNOTSUPP here for anything
other than arena seems like it might cause a backward compatibility
regression for existing global subprograms that accept standard tagged
pointers.

> +
> +		t = btf_type_by_id(btf, t->type);
> +	}
> +
> +	return 0;
> +}

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

  reply	other threads:[~2026-05-30  0:59 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-30  0:22 [PATCH bpf-next v2 0/5] bpf: Minimize annotations for arena programs Emil Tsalapatis
2026-05-30  0:22 ` [PATCH bpf-next v2 1/5] selftests/bpf: libarena: Add "arena" BTF type tag to __arena qualifier Emil Tsalapatis
2026-05-30  0:22 ` [PATCH bpf-next v2 2/5] verifier: parse BTF type tags for function arguments Emil Tsalapatis
2026-05-30  0:59   ` sashiko-bot [this message]
2026-06-01  5:12     ` Emil Tsalapatis
2026-06-01 18:37   ` Eduard Zingerman
2026-06-01 19:13     ` Emil Tsalapatis
2026-06-01 19:14       ` Eduard Zingerman
2026-05-30  0:22 ` [PATCH bpf-next v2 3/5] bpf: Allow subprogs to return arena pointers Emil Tsalapatis
2026-05-30  4:54   ` sashiko-bot
2026-06-01  5:09     ` Emil Tsalapatis
2026-06-01 19:01   ` Eduard Zingerman
2026-06-02  0:06     ` Emil Tsalapatis
2026-05-30  0:22 ` [PATCH bpf-next v2 4/5] selftests/bpf: Remove __arg_arena from the codebase Emil Tsalapatis
2026-05-30  5:03   ` sashiko-bot
2026-05-31  5:18     ` Alexei Starovoitov
2026-06-01  5:03       ` Emil Tsalapatis
2026-06-01 19:06   ` Eduard Zingerman
2026-05-30  0:22 ` [PATCH bpf-next v2 5/5] selftests/bpf: libarena: Directly return arena pointers from functions Emil Tsalapatis
2026-06-01 19:07   ` Eduard Zingerman

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=20260530005922.90CEE1F00893@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox