From: Aaron Lu <ziqianlu@bytedance.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Pu Lehui <pulehui@huawei.com>
Cc: stable@vger.kernel.org, Andrii Nakryiko <andrii@kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Wei Wei <weiwei.danny@bytedance.com>,
Yuchen Zhang <zhangyuchen.lcr@bytedance.com>
Subject: Re: Host panic in bpf verifier when loading bpf prog in 5.10 stable kernel
Date: Tue, 24 Jun 2025 11:52:16 +0800 [thread overview]
Message-ID: <20250624035216.GA316@bytedance> (raw)
In-Reply-To: <e9fa5e34-eacd-4f35-a250-2da75c9b7df8@huawei.com>
On Tue, Jun 24, 2025 at 09:32:54AM +0800, Pu Lehui wrote:
> Hi Aaron, Greg,
>
> Sorry for the late. Just found a fix [0] for this issue, we don't need to
> revert this bugfix series. Hope that will help!
>
> Link: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id=4bb7ea946a37
> [0]
I can confirm this also fixed the panic issue on top of 5.10.238.
Hi Greg,
The cherry pick is not clean but can be trivially fixed. I've appended
the patch I've used for test below for your reference in case you want
to take it and drop that revert series. Thanks.
From f0e1047ee11e4ab902a413736e4fd4fb32b278c8 Mon Sep 17 00:00:00 2001
From: Andrii Nakryiko <andrii@kernel.org>
Date: Thu, 9 Nov 2023 16:26:37 -0800
Subject: [PATCH] bpf: fix precision backtracking instruction iteration
commit 4bb7ea946a370707315ab774432963ce47291946 upstream.
Fix an edge case in __mark_chain_precision() which prematurely stops
backtracking instructions in a state if it happens that state's first
and last instruction indexes are the same. This situations doesn't
necessarily mean that there were no instructions simulated in a state,
but rather that we starting from the instruction, jumped around a bit,
and then ended up at the same instruction before checkpointing or
marking precision.
To distinguish between these two possible situations, we need to consult
jump history. If it's empty or contain a single record "bridging" parent
state and first instruction of processed state, then we indeed
backtracked all instructions in this state. But if history is not empty,
we are definitely not done yet.
Move this logic inside get_prev_insn_idx() to contain it more nicely.
Use -ENOENT return code to denote "we are out of instructions"
situation.
This bug was exposed by verifier_loop1.c's bounded_recursion subtest, once
the next fix in this patch set is applied.
Acked-by: Eduard Zingerman <eddyz87@gmail.com>
Fixes: b5dc0163d8fd ("bpf: precise scalar_value tracking")
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/r/20231110002638.4168352-3-andrii@kernel.org
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Aaron Lu <ziqianlu@bytedance.com>
---
kernel/bpf/verifier.c | 21 +++++++++++++++++++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index e6d50e371a2b8..75251870430e4 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -1796,12 +1796,29 @@ static int push_jmp_history(struct bpf_verifier_env *env,
/* Backtrack one insn at a time. If idx is not at the top of recorded
* history then previous instruction came from straight line execution.
+ * Return -ENOENT if we exhausted all instructions within given state.
+ *
+ * It's legal to have a bit of a looping with the same starting and ending
+ * insn index within the same state, e.g.: 3->4->5->3, so just because current
+ * instruction index is the same as state's first_idx doesn't mean we are
+ * done. If there is still some jump history left, we should keep going. We
+ * need to take into account that we might have a jump history between given
+ * state's parent and itself, due to checkpointing. In this case, we'll have
+ * history entry recording a jump from last instruction of parent state and
+ * first instruction of given state.
*/
static int get_prev_insn_idx(struct bpf_verifier_state *st, int i,
u32 *history)
{
u32 cnt = *history;
+ if (i == st->first_insn_idx) {
+ if (cnt == 0)
+ return -ENOENT;
+ if (cnt == 1 && st->jmp_history[0].idx == i)
+ return -ENOENT;
+ }
+
if (cnt && st->jmp_history[cnt - 1].idx == i) {
i = st->jmp_history[cnt - 1].prev_idx;
(*history)--;
@@ -2269,9 +2286,9 @@ static int __mark_chain_precision(struct bpf_verifier_env *env, int frame, int r
* Nothing to be tracked further in the parent state.
*/
return 0;
- if (i == first_idx)
- break;
i = get_prev_insn_idx(st, i, &history);
+ if (i == -ENOENT)
+ break;
if (i >= env->prog->len) {
/* This can happen if backtracking reached insn 0
* and there are still reg_mask or stack_mask
--
2.39.5
next prev parent reply other threads:[~2025-06-24 3:52 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-05 7:09 Host panic in bpf verifier when loading bpf prog in 5.10 stable kernel Aaron Lu
2025-06-16 7:06 ` Aaron Lu
2025-06-23 8:17 ` Greg Kroah-Hartman
2025-06-23 11:55 ` Aaron Lu
2025-06-23 12:03 ` Greg Kroah-Hartman
2025-06-24 1:32 ` Pu Lehui
2025-06-24 3:52 ` Aaron Lu [this message]
2025-06-24 6:41 ` Pu Lehui
2025-06-24 10:33 ` Greg Kroah-Hartman
2025-06-25 9:33 ` Aaron Lu
2025-07-12 13:42 ` Greg Kroah-Hartman
2025-07-15 2:10 ` Aaron Lu
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=20250624035216.GA316@bytedance \
--to=ziqianlu@bytedance.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=pulehui@huawei.com \
--cc=stable@vger.kernel.org \
--cc=weiwei.danny@bytedance.com \
--cc=zhangyuchen.lcr@bytedance.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