From: Yuan Chen <chenyuan@kylinos.cn>
To: bpf@vger.kernel.org
Cc: netdev@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Eduard Zingerman <eddyz87@gmail.com>,
Martin KaFai Lau <martin.lau@linux.dev>,
Shuah Khan <shuah@kernel.org>,
linux-kselftest@vger.kernel.org, Yuan Chen <chenyuan@kylinos.cn>
Subject: [PATCH bpf-next 1/2] bpf: Use a 32-bit compare in the array map gen_lookups
Date: Sun, 15 Nov 2026 18:25:58 +0800 [thread overview]
Message-ID: <20261115102559.465375-2-chenyuan@kylinos.cn> (raw)
In-Reply-To: <20261115102559.465375-1-chenyuan@kylinos.cn>
array_map_gen_lookup(), percpu_array_map_gen_lookup() and
array_of_map_gen_lookup() bound the inlined index with
BPF_JMP_IMM(BPF_JGE, idx, max_entries, ...). The index is a
zero-extended u32, but the immediate of a 64-bit JGE is sign-extended,
so for max_entries >= 0x80000000 the compare is never true.
With bypass_spec_v1, an out-of-range key can therefore produce
an address beyond the end of the array:
array->value + index * elem_size.
Without bypass_spec_v1 the index_mask AND keeps the access in bounds,
but such a key returns a masked element instead of NULL.
Creating such a map needs at least a 16 GiB allocation (max_entries
0x80000000, elem_size 8); the out-of-bounds path also needs a
CAP_PERFMON creator or mitigations=off.
Use BPF_JMP32_IMM() for the three compares, as commit 70504de0bb62
("xsk: Use a 32-bit compare in xsk_map_gen_lookup") did for
xsk_map_gen_lookup().
Fixes: b2157399cc98 ("bpf: prevent out-of-bounds speculation")
Signed-off-by: Yuan Chen <chenyuan@kylinos.cn>
---
kernel/bpf/arraymap.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c
index 508706d0c360..e7278e423f8e 100644
--- a/kernel/bpf/arraymap.c
+++ b/kernel/bpf/arraymap.c
@@ -230,10 +230,10 @@ static int array_map_gen_lookup(struct bpf_map *map, struct bpf_insn *insn_buf)
*insn++ = BPF_ALU64_IMM(BPF_ADD, map_ptr, offsetof(struct bpf_array, value));
*insn++ = BPF_LDX_MEM(BPF_W, ret, index, 0);
if (!map->bypass_spec_v1) {
- *insn++ = BPF_JMP_IMM(BPF_JGE, ret, map->max_entries, 4);
+ *insn++ = BPF_JMP32_IMM(BPF_JGE, ret, map->max_entries, 4);
*insn++ = BPF_ALU32_IMM(BPF_AND, ret, array->index_mask);
} else {
- *insn++ = BPF_JMP_IMM(BPF_JGE, ret, map->max_entries, 3);
+ *insn++ = BPF_JMP32_IMM(BPF_JGE, ret, map->max_entries, 3);
}
if (is_power_of_2(elem_size)) {
@@ -307,10 +307,10 @@ static int percpu_array_map_gen_lookup(struct bpf_map *map, struct bpf_insn *ins
*insn++ = BPF_LDX_MEM(BPF_W, BPF_REG_0, BPF_REG_2, 0);
if (!map->bypass_spec_v1) {
- *insn++ = BPF_JMP_IMM(BPF_JGE, BPF_REG_0, map->max_entries, 6);
+ *insn++ = BPF_JMP32_IMM(BPF_JGE, BPF_REG_0, map->max_entries, 6);
*insn++ = BPF_ALU32_IMM(BPF_AND, BPF_REG_0, array->index_mask);
} else {
- *insn++ = BPF_JMP_IMM(BPF_JGE, BPF_REG_0, map->max_entries, 5);
+ *insn++ = BPF_JMP32_IMM(BPF_JGE, BPF_REG_0, map->max_entries, 5);
}
*insn++ = BPF_ALU64_IMM(BPF_LSH, BPF_REG_0, 3);
@@ -1499,10 +1499,10 @@ static int array_of_map_gen_lookup(struct bpf_map *map,
*insn++ = BPF_ALU64_IMM(BPF_ADD, map_ptr, offsetof(struct bpf_array, value));
*insn++ = BPF_LDX_MEM(BPF_W, ret, index, 0);
if (!map->bypass_spec_v1) {
- *insn++ = BPF_JMP_IMM(BPF_JGE, ret, map->max_entries, 6);
+ *insn++ = BPF_JMP32_IMM(BPF_JGE, ret, map->max_entries, 6);
*insn++ = BPF_ALU32_IMM(BPF_AND, ret, array->index_mask);
} else {
- *insn++ = BPF_JMP_IMM(BPF_JGE, ret, map->max_entries, 5);
+ *insn++ = BPF_JMP32_IMM(BPF_JGE, ret, map->max_entries, 5);
}
if (is_power_of_2(elem_size))
*insn++ = BPF_ALU64_IMM(BPF_LSH, ret, ilog2(elem_size));
--
2.54.0
next prev parent reply other threads:[~2026-11-15 10:27 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-15 10:25 [PATCH bpf-next 0/2] bpf: Fix the array map gen_lookup index bounds check Yuan Chen
2026-11-15 10:25 ` Yuan Chen [this message]
2026-11-15 11:00 ` [PATCH bpf-next 1/2] bpf: Use a 32-bit compare in the array map gen_lookups bot+bpf-ci
2026-11-15 10:25 ` [PATCH bpf-next 2/2] selftests/bpf: Test the emitted bounds check of the array gen_lookup Yuan Chen
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=20261115102559.465375-2-chenyuan@kylinos.cn \
--to=chenyuan@kylinos.cn \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=linux-kselftest@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=netdev@vger.kernel.org \
--cc=shuah@kernel.org \
/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