From: chenyuan_fl@163.com
To: bpf@vger.kernel.org
Cc: Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Yuan Chen <chenyuan@kylinos.cn>
Subject: [PATCH bpf v2 1/2] bpf: Fix queue/stack map u32 index overflow
Date: Mon, 10 Aug 2026 17:28:13 +0800 [thread overview]
Message-ID: <20260810092814.2698521-2-chenyuan_fl@163.com> (raw)
In-Reply-To: <20260810092814.2698521-1-chenyuan_fl@163.com>
From: Yuan Chen <chenyuan@kylinos.cn>
The queue/stack map addresses elements[] with the product of a u32
head/tail index and value_size, but the storage itself is allocated in
64-bit arithmetic. When max_entries * value_size exceeds U32_MAX, the
product wraps and push/peek/pop operate on the wrong element, corrupting
map data and leaking stale values to user space.
The original bound check was removed by commit c85d69135a91 ("bpf: move
memory size checks to bpf_map_charge_init()"), which migrated only the
bytes-to-pages conversion and dropped the overflow guard, so oversized
queue/stack maps can be created again.
Restore the bound in queue_stack_map_alloc_check(): reject maps whose
element storage would exceed U32_MAX bytes, keeping the u32 index
multiplication overflow-free. Also reject max_entries == U32_MAX, which
would make the u32 capacity counter qs->size (max_entries + 1) wrap to
0 and permanently break the map.
Fixes: c85d69135a91 ("bpf: move memory size checks to bpf_map_charge_init()")
Signed-off-by: Yuan Chen <chenyuan@kylinos.cn>
---
kernel/bpf/queue_stack_maps.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/kernel/bpf/queue_stack_maps.c b/kernel/bpf/queue_stack_maps.c
index c1c9dee4dcdd..bb2453693b80 100644
--- a/kernel/bpf/queue_stack_maps.c
+++ b/kernel/bpf/queue_stack_maps.c
@@ -59,6 +59,16 @@ static int queue_stack_map_alloc_check(union bpf_attr *attr)
*/
return -E2BIG;
+ /*
+ * The u32 head/tail index is multiplied by value_size to address
+ * elements[], and qs->size (max_entries + 1) is stored in a u32.
+ * Bound the map size so neither the product nor the capacity
+ * counter can overflow.
+ */
+ if ((u64)attr->max_entries * attr->value_size > U32_MAX ||
+ attr->max_entries == U32_MAX)
+ return -E2BIG;
+
return 0;
}
--
2.54.0
next prev parent reply other threads:[~2026-08-10 9:28 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-10 9:28 [PATCH bpf v2 0/2] bpf: Fix queue/stack map u32 index overflow chenyuan_fl
2026-08-10 9:28 ` chenyuan_fl [this message]
2026-08-10 10:28 ` [PATCH bpf v2 1/2] " bot+bpf-ci
2026-08-13 22:16 ` Andrii Nakryiko
2026-08-10 9:28 ` [PATCH bpf v2 2/2] selftests/bpf: Add regression test for queue/stack map size limit chenyuan_fl
2026-08-10 9:39 ` sashiko-bot
2026-08-10 10:28 ` 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=20260810092814.2698521-2-chenyuan_fl@163.com \
--to=chenyuan_fl@163.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=chenyuan@kylinos.cn \
--cc=daniel@iogearbox.net \
/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