From: "Kumar Kartikeya Dwivedi" <memxor@gmail.com>
To: <sashiko-reviews@lists.linux.dev>
Cc: <bpf@vger.kernel.org>
Subject: Re: [PATCH bpf v3 1/2] bpf: Compare stack frames in regs_exact()
Date: Sat, 19 Sep 2026 03:26:10 +0200 [thread overview]
Message-ID: <DLIWH2PDV8ZI.3NEWOCLKS37IM@gmail.com> (raw)
In-Reply-To: <20260919010829.EE9211F00898@smtp.kernel.org>
On Sat Sep 19, 2026 at 3:08 AM CEST, sashiko-bot wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] bpf: Out-of-bounds array read in bpf_func() due to frameno aliasing
> --
>
> commit e17b850ba98b74f1dac193b96d8c0646c06a22d0
> Author: Kumar Kartikeya Dwivedi <memxor@gmail.com>
>
> bpf: Compare stack frames in regs_exact()
>
> This commit moves frameno into the type-specific metadata union, ahead of
> id, to compare stack frames in regs_exact(). It also moves the
> states_maybe_looping() boundary from frameno to precise.
>
>> diff --git a/include/linux/bpf_verifier.h b/include/linux/bpf_verifier.h
>> index a7202b44ab105..17be5f7df35af 100644
>> --- a/include/linux/bpf_verifier.h
>> +++ b/include/linux/bpf_verifier.h
>> @@ -45,6 +45,14 @@ struct bpf_reg_state {
>> union {
>> /* valid when type == PTR_TO_PACKET */
>> int range;
>> + /*
>> + * Inside the callee two registers can be both PTR_TO_STACK like
>> + * R1=fp-8 and R2=fp-8, but one of them points to this function stack
>> + * while another to the caller's stack. To differentiate them 'frameno'
>> + * is used which is an index in bpf_verifier_state->frame[] array
>> + * pointing to bpf_func_state.
>> + */
>> + u8 frameno;
>
> [Severity: High]
> Does moving frameno into this union cause an out-of-bounds array read in
> bpf_func()?
>
> For non-stack registers (like PTR_TO_MAP_VALUE), frameno will now contain
> arbitrary aliased bytes (such as the lowest byte of a map address).
>
> In kernel/bpf/verifier.c, functions like get_constant_map_key() and
> process_iter_arg() call bpf_func() unconditionally before verifying the
> register is a stack pointer:
>
> kernel/bpf/verifier.c:get_constant_map_key() {
> ...
> struct bpf_func_state *state = bpf_func(env, key);
> ...
> if (key->type != PTR_TO_STACK)
> return -EOPNOTSUPP;
> ...
> }
>
> bpf_func() evaluates env->cur_state->frame[reg->frameno]:
>
> include/linux/bpf_verifier.h:bpf_func() {
> struct bpf_verifier_state *cur = env->cur_state;
>
> return cur->frame[reg->frameno];
> }
>
> If a BPF program passes a non-stack register as an argument, and frameno
> evaluates to a large value (e.g. 255) due to aliasing, it indexes far
> outside the frame array, causing an out-of-bounds read and potential KASAN
> panics during program verification.
This seems correct, will fix.
next prev parent reply other threads:[~2026-09-19 1:26 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-19 0:43 [PATCH bpf v3 0/2] Compare stack frames in exact register states Kumar Kartikeya Dwivedi
2026-09-19 0:43 ` [PATCH bpf v3 1/2] bpf: Compare stack frames in regs_exact() Kumar Kartikeya Dwivedi
2026-09-19 1:08 ` sashiko-bot
2026-09-19 1:26 ` Kumar Kartikeya Dwivedi [this message]
2026-09-19 0:43 ` [PATCH bpf v3 2/2] selftests/bpf: Cover frame changes in bounded loops Kumar Kartikeya Dwivedi
2026-09-19 1:42 ` 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=DLIWH2PDV8ZI.3NEWOCLKS37IM@gmail.com \
--to=memxor@gmail.com \
--cc=bpf@vger.kernel.org \
--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.