[PATCH bpf 0/2] bpf: Fix queue/stack map u32 index overflow

[PATCH bpf 0/2] bpf: Fix queue/stack map u32 index overflow

[chenyuan_fl]

From: Yuan Chen <chenyuan@kylinos.cn>

queue/stack maps address their element storage with a u32 head/tail
index multiplied by value_size. The storage itself is allocated using
64-bit arithmetic, so a map with max_entries * value_size exceeding
U32_MAX can be created, and the u32 multiplication then wraps, making
push/peek/pop operate on the wrong element: map data gets corrupted and
stale values can leak to user space through peek.

The bound check that used to prevent this was removed by 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.

Patch 1 restores the bound at map creation time: a map whose element
storage would exceed U32_MAX bytes is rejected with -E2BIG, keeping the
u32 index multiplication overflow-free.
Patch 2 adds a regression test covering both map types and a
normal-sized control case.

Verification: built and run in QEMU - oversized queue/stack maps are
rejected with -E2BIG, normal-sized maps still work, and the
queue_stack_map selftest passes.

Yuan Chen (2):
  bpf: Fix queue/stack map u32 index overflow
  selftests/bpf: Add regression test for queue/stack map size limit

 kernel/bpf/queue_stack_maps.c                 |  7 ++++
 .../bpf/prog_tests/queue_stack_map.c          | 34 +++++++++++++++++++
 2 files changed, 41 insertions(+)

-- 
2.54.0

[PATCH 1/2] bpf: Fix queue/stack map u32 index overflow

[chenyuan_fl]

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 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.

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 | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/kernel/bpf/queue_stack_maps.c b/kernel/bpf/queue_stack_maps.c
index c1c9dee4dcdd..f9ff701ab27b 100644
--- a/kernel/bpf/queue_stack_maps.c
+++ b/kernel/bpf/queue_stack_maps.c
@@ -59,6 +59,13 @@ 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[]. Bound the map size so the product cannot overflow.
+	 */
+	if ((u64)attr->max_entries * attr->value_size > U32_MAX)
+		return -E2BIG;
+
 	return 0;
 }
 
-- 
2.54.0

[PATCH 2/2] selftests/bpf: Add regression test for queue/stack map size limit

[chenyuan_fl]

From: Yuan Chen <chenyuan@kylinos.cn>

queue/stack maps address elements[] with a u32 head/tail index
multiplied by value_size, so maps whose element storage exceeds
U32_MAX bytes must be rejected at creation time (see the fix in
queue_stack_map_alloc_check()).

Verify that creating a queue/stack map with max_entries * value_size
> U32_MAX (8192 * 1MB) fails with -E2BIG, and that a normal-sized
map is still created successfully.

Signed-off-by: Yuan Chen <chenyuan@kylinos.cn>
---
 .../bpf/prog_tests/queue_stack_map.c          | 34 +++++++++++++++++++
 1 file changed, 34 insertions(+)

diff --git a/tools/testing/selftests/bpf/prog_tests/queue_stack_map.c b/tools/testing/selftests/bpf/prog_tests/queue_stack_map.c
index 41441325e179..6f8ac285e719 100644
--- a/tools/testing/selftests/bpf/prog_tests/queue_stack_map.c
+++ b/tools/testing/selftests/bpf/prog_tests/queue_stack_map.c
@@ -101,8 +101,42 @@ static void test_queue_stack_map_by_type(int type)
 	bpf_object__close(obj);
 }
 
+static void test_queue_stack_map_alloc_check(void)
+{
+	LIBBPF_OPTS(bpf_map_create_opts, opts);
+	const __u32 big_value = 1 << 20; /* 1MB */
+	int fd, saved_errno;
+
+	/* Regression test for the u32 index overflow in queue/stack maps:
+	 * a map whose element storage (max_entries * value_size) exceeds
+	 * U32_MAX bytes must be rejected at creation time, otherwise the
+	 * u32 head/tail index multiplication wraps and push/peek/pop
+	 * address the wrong element. 8192 * 1MB = 8GB > U32_MAX.
+	 */
+	fd = bpf_map_create(BPF_MAP_TYPE_QUEUE, NULL, 0, big_value, 8192, &opts);
+	saved_errno = errno;
+	ASSERT_LT(fd, 0, "queue_oversize_fd");
+	ASSERT_EQ(saved_errno, E2BIG, "queue_oversize_errno");
+	if (fd >= 0)
+		close(fd);
+
+	fd = bpf_map_create(BPF_MAP_TYPE_STACK, NULL, 0, big_value, 8192, &opts);
+	saved_errno = errno;
+	ASSERT_LT(fd, 0, "stack_oversize_fd");
+	ASSERT_EQ(saved_errno, E2BIG, "stack_oversize_errno");
+	if (fd >= 0)
+		close(fd);
+
+	/* A normal-sized map must still be created successfully. */
+	fd = bpf_map_create(BPF_MAP_TYPE_QUEUE, NULL, 0, 64, 100, &opts);
+	ASSERT_GE(fd, 0, "queue_normal_fd");
+	if (fd >= 0)
+		close(fd);
+}
+
 void test_queue_stack_map(void)
 {
 	test_queue_stack_map_by_type(QUEUE);
 	test_queue_stack_map_by_type(STACK);
+	test_queue_stack_map_alloc_check();
 }
-- 
2.54.0

Re: [PATCH 2/2] selftests/bpf: Add regression test for queue/stack map size limit

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Multi-line comment opening `/*` is not on its own line.
--

--- Patch [2]: [PATCH 2/2] selftests/bpf: Add regression test for queue/stack map size limit ---
commit e79d16bed784907a39f11792c9c1497efb8fd26f
Author: Yuan Chen <chenyuan@kylinos.cn>

selftests/bpf: Add regression test for queue/stack map size limit

This commit adds a regression test to verify that queue and stack maps reject
creation if their element storage size exceeds U32_MAX bytes. It tests both
queue and stack maps with an oversized configuration, ensuring they fail with
-E2BIG, and also verifies that a normal-sized map is successfully created.

> diff --git a/tools/testing/selftests/bpf/prog_tests/queue_stack_map.c b/tools/testing/selftests/bpf/prog_tests/queue_stack_map.c
> index 41441325e1794..6f8ac285e7196 100644
> --- a/tools/testing/selftests/bpf/prog_tests/queue_stack_map.c
> +++ b/tools/testing/selftests/bpf/prog_tests/queue_stack_map.c
[ ... ]
> @@ -101,8 +101,42 @@ static void test_queue_stack_map_by_type(int type)
>  	bpf_object__close(obj);
>  }
>  
> +static void test_queue_stack_map_alloc_check(void)
> +{
> +	LIBBPF_OPTS(bpf_map_create_opts, opts);
> +	const __u32 big_value = 1 << 20; /* 1MB */
> +	int fd, saved_errno;
> +
> +	/* Regression test for the u32 index overflow in queue/stack maps:

[Severity: Low]
This isn't a bug, but should this multi-line comment follow the BPF subsystem
comment style by placing the opening /* on its own line?

> +	 * a map whose element storage (max_entries * value_size) exceeds
> +	 * U32_MAX bytes must be rejected at creation time, otherwise the
> +	 * u32 head/tail index multiplication wraps and push/peek/pop
> +	 * address the wrong element. 8192 * 1MB = 8GB > U32_MAX.
> +	 */
> +	fd = bpf_map_create(BPF_MAP_TYPE_QUEUE, NULL, 0, big_value, 8192, &opts);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260807020548.1376979-1-chenyuan_fl@163.com?part=2

Re: [PATCH 1/2] bpf: Fix queue/stack map u32 index overflow

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Medium] When `attr->max_entries` is exactly `U32_MAX` and `attr->value_size` is 1, the internal map capacity tracker `qs->size` silently truncates to 0, permanently breaking the map while still allocating 4GB of kernel memory.
--

--- Patch [1]: [PATCH 1/2] bpf: Fix queue/stack map u32 index overflow ---
commit 47dbebc907a9c220d2feebeadd6501394e5a0348
Author: Yuan Chen <chenyuan@kylinos.cn>
Subject: bpf: Fix queue/stack map u32 index overflow

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. This patch restores a bound check to reject maps whose
element storage would exceed U32_MAX bytes.

> --- a/kernel/bpf/queue_stack_maps.c
> +++ b/kernel/bpf/queue_stack_maps.c
> @@ -59,6 +59,13 @@ 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[]. Bound the map size so the product cannot overflow.
> +	 */
> +	if ((u64)attr->max_entries * attr->value_size > U32_MAX)
> +		return -E2BIG;
> +

[Severity: Medium]
This is a pre-existing issue, but could this check still allow a truncation
in qs->size when attr->max_entries is exactly U32_MAX and attr->value_size
is 1?

If a map is created with those attributes, it bypasses the bounds check
above. Then in queue_stack_map_alloc(), the size is incremented by 1:

kernel/bpf/queue_stack_maps.c:queue_stack_map_alloc() {
    ...
    u64 size, queue_size, cost;
    ...
    size = attr->max_entries + 1;
    ...
    qs->size = size;
    ...
}

Because qs->size is declared as a u32 in struct bpf_queue_stack:

    u32 size; /* max_entries + 1 */

does assigning size (which is U32_MAX + 1) cause qs->size to silently
truncate to 0? This appears to result in a 4GB map allocation that remains
permanently empty since its capacity tracker is 0.

>  	return 0;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260807020548.1376979-1-chenyuan_fl@163.com?part=1