From: bot+bpf-ci@kernel.org
To: xukuohai@huaweicloud.com,bpf@vger.kernel.org,linux-kernel@vger.kernel.org
Cc: ast@kernel.org,daniel@iogearbox.net,andrii@kernel.org,eddyz87@gmail.com,memxor@gmail.com,emil@etsalapatis.com,yonghong.song@linux.dev,ast@kernel.org,andrii@kernel.org,daniel@iogearbox.net,martin.lau@kernel.org,eddyz87@gmail.com,yonghong.song@linux.dev,mason@kernel.org,ihor.solodrai@linux.dev
Subject: Re: [PATCH bpf-next 08/16] bpf: Extend syscall to accept arena percpu information
Date: Tue, 20 Oct 2026 14:17:14 +0000 (UTC) [thread overview]
Message-ID: <9e3c68360cf25fad73a6c9397f0e77d8b35d8a6cb72d129b66328ea4fe7bfe18@mail.kernel.org> (raw)
In-Reply-To: <2f1a53eb72a6fdb93346cb4e1d04a5d472177b1c.1792503001.git.xukuohai@huawei.com>
[-- Attachment #1: Type: text/plain, Size: 3998 bytes --]
> bpf: Extend syscall to accept arena percpu information
TL;DR:
- BPF_MAP_CREATE may silently accept arena percpu fields for non-arena map
types, blocking future uapi use
- A nonzero percpu chunk offset with zero size is not validated
> diff --git a/kernel/bpf/arena.c b/kernel/bpf/arena.c
> index 868589f07330..05cd6397adae 100644
> --- a/kernel/bpf/arena.c
> +++ b/kernel/bpf/arena.c
[ ... ]
> @@ -298,6 +301,17 @@ static struct bpf_map *arena_map_alloc(union bpf_attr *attr)
> /* user vma must not cross 32-bit boundary */
> return ERR_PTR(-ERANGE);
>
> + if (attr->arena_percpu_chunk_sz) {
> + u64 offset = attr->arena_percpu_chunk_off;
> + u64 size = attr->arena_percpu_chunk_sz;
> +
> + if (!IS_ALIGNED(offset, PAGE_SIZE) || !IS_ALIGNED(size, PAGE_SIZE))
> + return ERR_PTR(-EINVAL);
> +
> + if (offset > vm_range || size > (vm_range - offset) / nr_cpu_ids)
> + return ERR_PTR(-E2BIG);
> + }
> +
> kern_vm = get_vm_area(KERN_VM_SZ, VM_SPARSE | VM_USERMAP);
> if (!kern_vm)
> return ERR_PTR(-ENOMEM);
[ ... ]
> @@ -311,6 +325,10 @@ static struct bpf_map *arena_map_alloc(union bpf_attr *attr)
> if (arena->user_vm_start)
> arena->user_vm_end = arena->user_vm_start + vm_range;
>
> + arena->percpu_chunk_sz = attr->arena_percpu_chunk_sz;
> + if (attr->arena_percpu_chunk_sz)
> + arena->percpu_chunk_off = attr->arena_percpu_chunk_off;
> +
If userspace passes arena_percpu_chunk_off != 0 with arena_percpu_chunk_sz
== 0, is the offset ever validated?
In that case the alignment and range checks above are skipped, the offset is
ignored, and arena->percpu_chunk_off stays 0.
The commit message says "Both are checked at arena creation time", which
only holds when arena_percpu_chunk_sz is nonzero. The excl_prog_hash
handling in map_create_alloc() already rejects the matching case of a size
without a hash:
} else if (attr->excl_prog_hash_size) {
...
err = -EINVAL;
Should arena_map_alloc() return -EINVAL when arena_percpu_chunk_off is
nonzero but arena_percpu_chunk_sz is 0?
[ ... ]
> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> index 849bc9136299..240c7349284d 100644
> --- a/kernel/bpf/syscall.c
> +++ b/kernel/bpf/syscall.c
> @@ -1396,7 +1396,7 @@ static int map_check_btf(struct bpf_map *map, struct bpf_token *token,
> return ret;
> }
>
> -#define BPF_MAP_CREATE_LAST_FIELD excl_prog_hash_size
> +#define BPF_MAP_CREATE_LAST_FIELD arena_percpu_chunk_sz
> /* called via syscall */
> static int map_create_alloc(union bpf_attr *attr, bpfptr_t uattr, struct bpf_verifier_log *log,
> struct bpf_map **mapp, struct bpf_token **tokenp)
Does raising BPF_MAP_CREATE_LAST_FIELD here make CHECK_ATTR accept
arena_percpu_chunk_off and arena_percpu_chunk_sz for every map type?
Only arena_map_alloc() reads them, and map_create_alloc() has no check for
these fields. For example, BPF_MAP_CREATE with map_type =
BPF_MAP_TYPE_HASH and arena_percpu_chunk_sz = 4096 succeeds and the values
are silently dropped.
map_create_alloc() already rejects the comparable per-type field:
if (attr->map_type != BPF_MAP_TYPE_BLOOM_FILTER &&
attr->map_type != BPF_MAP_TYPE_ARENA &&
attr->map_type != BPF_MAP_TYPE_RHASH &&
attr->map_extra != 0) {
bpf_log(log, "Invalid map_extra.\n");
return -EINVAL;
}
Since current kernels will accept any value in these fields, they can never
later be given a meaning for other map types, or for the offset-only case
above. Bad loader input, such as percpu info attached to the wrong map, is
also never reported. No later commit in the series (through 08224ba2de19)
adds this check.
Should map_create_alloc() return -EINVAL when map_type is not
BPF_MAP_TYPE_ARENA and either arena_percpu_chunk_off or
arena_percpu_chunk_sz is nonzero?
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/39434884362
next prev parent reply other threads:[~2026-10-20 14:17 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-20 13:22 [PATCH bpf-next 00/16] Add percpu variable support for bpf arena Xu Kuohai
2026-10-20 13:22 ` [PATCH bpf-next 01/16] libbpf: Collect arena percpu data section Xu Kuohai
2026-10-20 14:17 ` bot+bpf-ci
2026-10-20 13:22 ` [PATCH bpf-next 02/16] libbpf: Create arena percpu chunk from the arena percpu ELF section Xu Kuohai
2026-10-20 14:17 ` bot+bpf-ci
2026-10-20 13:22 ` [PATCH bpf-next 03/16] libbpf: Place the percpu chunks in the bpf arena Xu Kuohai
2026-10-20 13:22 ` [PATCH bpf-next 04/16] libbpf: Copy the percpu chunks into " Xu Kuohai
2026-10-20 14:17 ` bot+bpf-ci
2026-10-20 13:22 ` [PATCH bpf-next 05/16] libbpf: Add the arena percpu chunk attribute to map creation options Xu Kuohai
2026-10-20 14:17 ` bot+bpf-ci
2026-10-20 13:22 ` [PATCH bpf-next 06/16] libbpf: Relocate arena percpu access instructions Xu Kuohai
2026-10-20 14:29 ` bot+bpf-ci
2026-10-20 13:22 ` [PATCH bpf-next 07/16] libbpf: Add arena percpu feature probe Xu Kuohai
2026-10-20 14:17 ` bot+bpf-ci
2026-10-20 13:22 ` [PATCH bpf-next 08/16] bpf: Extend syscall to accept arena percpu information Xu Kuohai
2026-10-20 14:17 ` bot+bpf-ci [this message]
2026-10-20 13:22 ` [PATCH bpf-next 09/16] bpf: Teach verifier about arena percpu instructions Xu Kuohai
2026-10-20 14:29 ` bot+bpf-ci
2026-10-20 13:22 ` [PATCH bpf-next 10/16] bpf, x86: Add support for arena percpu Xu Kuohai
2026-10-20 13:22 ` [PATCH bpf-next 11/16] bpf, arm64: " Xu Kuohai
2026-10-20 14:17 ` bot+bpf-ci
2026-10-20 13:22 ` [PATCH bpf-next 12/16] libbpf: Introduce arena percpu helpers for user space Xu Kuohai
2026-10-20 14:17 ` bot+bpf-ci
2026-10-20 13:22 ` [PATCH bpf-next 13/16] bpftool: Emit the arena percpu datasec into skeleton Xu Kuohai
2026-10-20 13:22 ` [PATCH bpf-next 14/16] selftests/bpf: Add test for arena percpu-only object Xu Kuohai
2026-10-20 14:17 ` bot+bpf-ci
2026-10-20 13:23 ` [PATCH bpf-next 15/16] selftests/bpf: Add test for mixed arena percpu object Xu Kuohai
2026-10-20 13:23 ` [PATCH bpf-next 16/16] selftests/bpf: Add test for arena percpu bounds Xu Kuohai
2026-10-20 14:17 ` bot+bpf-ci
2026-10-20 14:47 ` [PATCH bpf-next 00/16] Add percpu variable support for bpf arena Alexei Starovoitov
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=9e3c68360cf25fad73a6c9397f0e77d8b35d8a6cb72d129b66328ea4fe7bfe18@mail.kernel.org \
--to=bot+bpf-ci@kernel.org \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=emil@etsalapatis.com \
--cc=ihor.solodrai@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.lau@kernel.org \
--cc=mason@kernel.org \
--cc=memxor@gmail.com \
--cc=xukuohai@huaweicloud.com \
--cc=yonghong.song@linux.dev \
/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
all inboxes | Powered by JetHome®