All of lore.kernel.org
 help / color / mirror / Atom feed
From: chenyuan_fl@163.com
To: bpf@vger.kernel.org
Cc: ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
	andrii.nakryiko@gmail.com, Yuan Chen <chenyuan@kylinos.cn>,
	stable@vger.kernel.org
Subject: [PATCH bpf v4 1/2] bpf: Fix queue/stack map u32 index overflow
Date: Mon, 24 Aug 2026 16:33:26 +0800	[thread overview]
Message-ID: <20260824083327.1708560-2-chenyuan_fl@163.com> (raw)
In-Reply-To: <20260824083327.1708560-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>
---
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 | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/kernel/bpf/queue_stack_maps.c b/kernel/bpf/queue_stack_maps.c
index c1c9dee4dcdd..0d9e0b807a50 100644
--- a/kernel/bpf/queue_stack_maps.c
+++ b/kernel/bpf/queue_stack_maps.c
@@ -59,6 +59,15 @@ 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 max_entries so neither the product nor the capacity
+	 * counter can wrap (this also rejects max_entries == U32_MAX).
+	 */
+	if (attr->max_entries >= U32_MAX / attr->value_size)
+		return -E2BIG;
+
 	return 0;
 }
 
-- 
2.43.0


  reply	other threads:[~2026-08-24  8:34 UTC|newest]

Thread overview: 19+ 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       ` chenyuan_fl [this message]
2026-08-24  8:47         ` [PATCH bpf v4 1/2] " 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             ` [PATCH bpf v5 1/2] " chenyuan_fl
2026-08-31  7:13               ` 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-09-02 23:30             ` [PATCH bpf v5 0/2] bpf: Fix queue/stack map u32 index overflow patchwork-bot+netdevbpf
2026-08-24  8:33       ` [PATCH bpf v4 2/2] selftests/bpf: Add regression test for queue/stack map size limit 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=20260824083327.1708560-2-chenyuan_fl@163.com \
    --to=chenyuan_fl@163.com \
    --cc=andrii.nakryiko@gmail.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 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.