BPF List
 help / color / mirror / Atom feed
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>,
	stable@vger.kernel.org
Subject: [PATCH bpf v5 1/2] bpf: Fix queue/stack map u32 index overflow
Date: Mon, 31 Aug 2026 14:32:25 +0800	[thread overview]
Message-ID: <20260831063226.621309-2-chenyuan_fl@163.com> (raw)
In-Reply-To: <20260831063226.621309-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 reaches or 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.
max_entries == U32_MAX would also make the u32 capacity counter
qs->size (max_entries + 1) wrap to 0 and permanently break the map.

The original bound check was removed by commit a37fb7ef24a4 ("bpf:
Eliminate rlimit-based memory accounting for queue_stack_maps maps"),
which deleted the bpf_map_charge_init() call and with it the
U32_MAX - PAGE_SIZE check that had earlier been moved into
bpf_map_charge_init() by c85d69135a91.  Oversized queue/stack maps can
therefore be created again.

Restore the bound in queue_stack_map_alloc_check() with a single
comparison that rejects any max_entries/value_size combination whose
element storage would reach or exceed U32_MAX bytes, keeping the u32
index multiplication overflow-free and the capacity counter valid.

Fixes: a37fb7ef24a4 ("bpf: Eliminate rlimit-based memory accounting for queue_stack_maps maps")
Cc: stable@vger.kernel.org
Signed-off-by: Yuan Chen <chenyuan@kylinos.cn>
---
v5: drop the explanatory comment, as suggested by Andrii Nakryiko

v4: simplify the bound to a single division-based comparison as
    suggested by Andrii Nakryiko; this also rejects max_entries == U32_MAX

 kernel/bpf/queue_stack_maps.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/kernel/bpf/queue_stack_maps.c b/kernel/bpf/queue_stack_maps.c
index c1c9dee4dcdd..b5628e414981 100644
--- a/kernel/bpf/queue_stack_maps.c
+++ b/kernel/bpf/queue_stack_maps.c
@@ -59,6 +59,9 @@ static int queue_stack_map_alloc_check(union bpf_attr *attr)
 		 */
 		return -E2BIG;
 
+	if (attr->max_entries >= U32_MAX / attr->value_size)
+		return -E2BIG;
+
 	return 0;
 }
 
-- 
2.43.0


  reply	other threads:[~2026-08-31  6:33 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-10 13:59 [PATCH bpf v3 0/2] bpf: Fix queue/stack map u32 index overflow chenyuan_fl
2026-08-10 13:59 ` [PATCH bpf v3 1/2] " chenyuan_fl
2026-08-10 13:59 ` [PATCH bpf v3 2/2] selftests/bpf: Add regression test for queue/stack map size limit chenyuan_fl
2026-08-10 14:49   ` bot+bpf-ci
2026-08-13 22:19   ` Andrii Nakryiko
2026-08-24  8:33     ` [PATCH bpf v4 0/2] bpf: Fix queue/stack map u32 index overflow chenyuan_fl
2026-08-24  8:33       ` [PATCH bpf v4 1/2] " chenyuan_fl
2026-08-24  8:47         ` sashiko-bot
2026-08-28  0:04         ` Andrii Nakryiko
2026-08-31  6:32           ` [PATCH bpf v5 0/2] " chenyuan_fl
2026-08-31  6:32             ` chenyuan_fl [this message]
2026-08-31  7:13               ` [PATCH bpf v5 1/2] " bot+bpf-ci
2026-08-31  6:32             ` [PATCH bpf v5 2/2] selftests/bpf: Add regression test for queue/stack map size limit chenyuan_fl
2026-08-31  7:13               ` bot+bpf-ci
2026-08-24  8:33       ` [PATCH bpf v4 " chenyuan_fl
2026-08-24  8:43         ` sashiko-bot
2026-08-24  9:25         ` bot+bpf-ci
2026-08-28  0:04         ` Andrii Nakryiko

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=20260831063226.621309-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 \
    --cc=stable@vger.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