From: Luis Gerhorst <luis.gerhorst@fau.de>
To: Eduard Zingerman <eddyz87@gmail.com>
Cc: andrii@kernel.org, ast@kernel.org, bpf@vger.kernel.org,
daniel@iogearbox.net, haoluo@google.com,
john.fastabend@gmail.com, jolsa@kernel.org, kpsingh@kernel.org,
linux-kernel@vger.kernel.org, martin.lau@linux.dev,
sdf@fomichev.me, song@kernel.org,
syzkaller-bugs@googlegroups.com, yonghong.song@linux.dev
Subject: Re: [syzbot] [bpf?] KASAN: slab-use-after-free Read in do_check
Date: Wed, 11 Jun 2025 16:03:59 +0200 [thread overview]
Message-ID: <87frg6gysw.fsf@fau.de> (raw)
In-Reply-To: <38862a832b91382cddb083dddd92643bed0723b8.camel@gmail.com> (Eduard Zingerman's message of "Wed, 11 Jun 2025 06:02:55 -0700")
Eduard Zingerman <eddyz87@gmail.com> writes:
> Accessed memory is freed at an error path in push_stack():
>
> static struct bpf_verifier_state *push_stack(...)
> {
> ...
> err:
> free_verifier_state(env->cur_state, true); // <-- KASAN points here
> ...
> }
>
> And is accessed after being freed here:
>
> static int do_check(struct bpf_verifier_env *env)
> {
> ...
> err = do_check_insn(env, &do_print_state);
> KASAN --> if (state->speculative && error_recoverable_with_nospec(err)) ...
> ...
> }
>
> [...]
>
> Either 'state = env->cur_state' is needed after 'do_check_insn()' or
> error path should not free env->cur_state (seems logical).
Sorry, this was my error from [1]. Thanks for the pointer.
Yes, I think the former makes sense (with the respective `state &&`
added to the if).
The latter might also be possible, but I guess it would require more
significant changes.
state->speculative does not make sense if the error path of push_stack()
ran. In that case, `state->speculative &&
error_recoverable_with_nospec(err)` as a whole should already never
evaluate to true (because all cases where push_stack() fails also return
a non-recoverable error -ENOMEM/-EFAULT).
Alternatively to adding `state = env->cur_state` and `state &&`, turning
the check around would avoid the use-after-free. However, I think your
idea is better because it is more explicit compared to this:
if (error_recoverable_with_nospec(err) && state->speculative) ...
Does this make sense to you? If yes I can send the fix later today.
I will also check that all other paths calling free_verifier_state() are
sane. So far it looks good.
The later
if (state->speculative && cur_aux(env)->nospec_result) {
should already be fine, because !env->cur_state should imply that the
previous if raises the error.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=d6f1c85f22534d2d9fea9b32645da19c91ebe7d2
next prev parent reply other threads:[~2025-06-11 14:14 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-11 12:36 [syzbot] [bpf?] KASAN: slab-use-after-free Read in do_check syzbot
2025-06-11 13:02 ` Eduard Zingerman
2025-06-11 14:03 ` Luis Gerhorst [this message]
2025-06-11 17:20 ` Eduard Zingerman
2025-06-11 21:07 ` [PATCH bpf-next] bpf: Fix state use-after-free on push_stack() err Luis Gerhorst
2025-06-11 22:23 ` Eduard Zingerman
2025-06-11 23:10 ` patchwork-bot+netdevbpf
2025-06-11 21:14 ` [PATCH bpf-next] bpf: Remove redundant free_verifier_state()/pop_stack() Luis Gerhorst
2025-06-11 22:36 ` Eduard Zingerman
2025-06-13 9:01 ` [PATCH bpf-next v2] " Luis Gerhorst
2025-06-13 21:17 ` Eduard Zingerman
2025-06-13 22:06 ` Alexei Starovoitov
2025-06-13 9:07 ` [PATCH bpf-next] " Luis Gerhorst
2025-06-11 21:32 ` [syzbot] [bpf?] KASAN: slab-use-after-free Read in do_check Luis Gerhorst
2025-06-11 21:43 ` Eduard Zingerman
2025-06-11 21:40 ` Eduard Zingerman
2025-06-11 23:00 ` syzbot
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=87frg6gysw.fsf@fau.de \
--to=luis.gerhorst@fau.de \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=sdf@fomichev.me \
--cc=song@kernel.org \
--cc=syzkaller-bugs@googlegroups.com \
--cc=yonghong.song@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.