BPF List
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Justin Suess" <utilityemal77@gmail.com>
Cc: linux-security-module@vger.kernel.org, bpf@vger.kernel.org
Subject: Re: [RFC PATCH bpf-next 10/12] bpf: support "__uninit" iterator arguments in generic kfuncs
Date: Tue, 06 Oct 2026 00:37:16 +0000	[thread overview]
Message-ID: <20261006003716.CC7791F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20261006002020.2890858-11-utilityemal77@gmail.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] bpf: aliased __uninit and __iter arguments bypass verifier initialization checks
--

commit e08b0892f34d46a76c048cb46111b4956bcddfe8
Author: Justin Suess <utilityemal77@gmail.com>

bpf: support "__uninit" iterator arguments in generic kfuncs

This commit allows generic kfuncs to initialize iterator arguments by
recognizing the __uninit suffix. It updates process_iter_arg() to treat
these marked arguments similarly to how bpf_iter_<type>_new() operates on
uninitialized iterator state.

> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 066c4b838b858..3294b2a431674 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c

[ ... ]

> @@ -8363,8 +8386,16 @@ static int process_iter_arg(struct bpf_verifier_env *env, struct bpf_reg_state *
>  	t = btf_type_by_id(meta->btf, btf_id);
>  	nr_slots = t->size / BPF_REG_SIZE;
>  
> -	if (is_iter_new_kfunc(meta)) {
> -		/* bpf_iter_<type>_new() expects pointer to uninit iter state */
> +	/*
> +	 * Whether this argument is the iterator the call initializes, rather
> +	 * than an initialized one it operates on.
> +	 */
> +	init = is_iter_new_kfunc(meta) ||
> +	       is_kfunc_arg_iter_init(meta, arg,
> +				      &btf_params(meta->func_proto)[arg]);
> +
> +	if (init) {
> +		/* expects a pointer to uninit iter state */

[Severity: Medium]
Is there a risk of bypassing verifier initialization checks if a BPF program
passes aliased registers for these arguments?

When check_func_args() evaluates kfunc arguments sequentially, an __uninit
argument will set init to true here, and process_iter_arg() will immediately
mark the stack slots as initialized via mark_stack_slots_iter().

If a subsequent __iter argument to the same kfunc aliases those exact same
stack slots, its is_iter_reg_valid_init() check will incorrectly pass because
the previous argument just marked them as initialized. This could allow
uninitialized stack memory to be passed where an initialized iterator is
expected.

While this is mitigated in this patch series because the newly introduced
kfunc uses different BTF types for its iterators (causing the bypass to fail
strict BTF ID checks), does this structure need to be fixed to prevent future
issues when kfuncs use matching iterator types?

Should state modifications like mark_stack_slots_iter() be deferred until
all arguments are successfully validated, similar to how
ARG_PTR_TO_UNINIT_MEM is handled?

>  		if (!is_iter_reg_valid_uninit(env, reg, nr_slots)) {
>  			verbose(env, "expected uninitialized iter_%s as %s\n",
>  				iter_type_str(meta->btf, btf_id), reg_arg_name(env, argno));

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261006002020.2890858-1-utilityemal77@gmail.com?part=10

  reply	other threads:[~2026-10-06  0:37 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-06  0:20 [RFC PATCH bpf-next 00/12] fs: unified VFS ancestor walk for Landlock and BPF Justin Suess
2026-10-06  0:20 ` [RFC PATCH bpf-next 01/12] namei: introduce __path_walk_parent() Justin Suess
2026-10-06  0:27   ` sashiko-bot
2026-10-06  0:20 ` [RFC PATCH bpf-next 02/12] namei: add vfs_walk_ancestors() Justin Suess
2026-10-06  0:30   ` sashiko-bot
2026-10-06  0:20 ` [RFC PATCH bpf-next 03/12] landlock: convert ancestor walk to vfs_walk_ancestors() Justin Suess
2026-10-06  0:27   ` sashiko-bot
2026-10-06  1:10   ` bot+bpf-ci
2026-10-06  0:20 ` [RFC PATCH bpf-next 04/12] bpf: mark struct path trusted Justin Suess
2026-10-06  0:34   ` sashiko-bot
2026-10-06  1:10   ` bot+bpf-ci
2026-10-06  0:20 ` [RFC PATCH bpf-next 05/12] namei: make vfs_walk_ancestors() stepwise Justin Suess
2026-10-06  0:30   ` sashiko-bot
2026-10-06  0:20 ` [RFC PATCH bpf-next 06/12] bpf: add a path ancestor iterator Justin Suess
2026-10-06  0:30   ` sashiko-bot
2026-10-06  1:11   ` bot+bpf-ci
2026-10-06  0:20 ` [RFC PATCH bpf-next 07/12] selftests/bpf: exercise the " Justin Suess
2026-10-06  0:28   ` sashiko-bot
2026-10-06  1:10   ` bot+bpf-ci
2026-10-06  0:20 ` [RFC PATCH bpf-next 08/12] fs: add mnt_undo_legitimize() Justin Suess
2026-10-06  0:28   ` sashiko-bot
2026-10-06  0:20 ` [RFC PATCH bpf-next 09/12] namei: add an rcu-walk mode to the ancestor walk Justin Suess
2026-10-06  0:33   ` sashiko-bot
2026-10-06  1:10   ` bot+bpf-ci
2026-10-06  0:20 ` [RFC PATCH bpf-next 10/12] bpf: support "__uninit" iterator arguments in generic kfuncs Justin Suess
2026-10-06  0:37   ` sashiko-bot [this message]
2026-10-06 14:58     ` Justin Suess
2026-10-06  0:20 ` [RFC PATCH bpf-next 11/12] bpf: add a lockless path ancestor iterator Justin Suess
2026-10-06  0:31   ` sashiko-bot
2026-10-06  1:10   ` bot+bpf-ci
2026-10-06 14:44     ` Justin Suess
2026-10-06  0:20 ` [RFC PATCH bpf-next 12/12] selftests/bpf: exercise the " Justin Suess
2026-10-06  0:25   ` sashiko-bot
2026-10-06  1:10   ` 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=20261006003716.CC7791F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=utilityemal77@gmail.com \
    /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