From: sashiko-bot@kernel.org
To: "Kumar Kartikeya Dwivedi" <memxor@gmail.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v1 03/10] bpf: Turn loads of __arena pointer members into arena pointers
Date: Mon, 12 Oct 2026 14:00:15 +0000 [thread overview]
Message-ID: <sashiko-outbox-168226@kernel.org> (raw)
In-Reply-To: <20261012133711.4030594-4-memxor@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] bpf: arena_member fixup corrupts PTR_TO_MEM scalar loads
--
commit 5458ef081d9f29cc60192d4b6fde6d8fd3989b75
Author: Kumar Kartikeya Dwivedi <memxor@gmail.com>
bpf: Turn loads of __arena pointer members into arena pointers
This commit translates loads of __arena pointer members in kernel structs
into arena pointers in the verifier. It appends a fixup to subtract the
kernel's virtual memory start address from the loaded value, and adds logic
to ensure paths disagreeing on member types are rejected.
> diff --git a/kernel/bpf/fixups.c b/kernel/bpf/fixups.c
> index b2fa7e8bedf3a..bbb653df6b6f0 100644
> --- a/kernel/bpf/fixups.c
> +++ b/kernel/bpf/fixups.c
[ ... ]
> @@ -870,6 +870,36 @@ int bpf_opt_subreg_zext_lo32_rnd_hi32(struct bpf_verifier_env *env,
> * struct __sk_buff -> struct sk_buff
> * struct bpf_sock_ops -> struct sock
> */
> +/*
> + * A load through an __arena pointer member of a kernel struct reads the kernel
> + * address of arena memory. Append the conversion to the arena pointer form,
> + * (u32)(kaddr - kern_vm_start), that the struct_ops trampoline applies to
> + * __arena arguments. A __nullable member keeps NULL as NULL, tested on the
> + * full kernel address. Returns the number of insns in @buf, 0 when the insn
> + * loads no such member, or an error when it does so on some paths only.
> + */
> +static int arena_member_fixup(struct bpf_verifier_env *env, int idx, struct bpf_insn *insn,
> + struct bpf_insn *buf)
> +{
> + struct bpf_insn_aux_data *aux = &env->insn_aux_data[idx];
> + int cnt = 0;
> + u32 base;
> +
> + if (!aux->arena_member)
> + return 0;
> + if (aux->non_arena_member) {
> + verbose(env, "an insn loads an arena pointer member on one path and a different member on another\n");
> + return -EINVAL;
> + }
[Severity: High]
Because non_arena_member might not be set by the PTR_TO_MEM path (as noted
below), could this check fail to reject the mismatch?
If it fails to reject, arena_member_fixup() blindly appends a
SUB kern_vm_start instruction to the shared load. At runtime, if the
PTR_TO_MEM path executes, its scalar load would be corrupted by the
subtraction, potentially leading to out-of-bounds access or data corruption
if the result is used as an index or offset.
> +
> + base = bpf_arena_get_kern_vm_start(env->prog->aux->arena);
> + buf[cnt++] = *insn;
> + if (aux->arena_member_nullable)
> + buf[cnt++] = BPF_JMP_IMM(BPF_JEQ, insn->dst_reg, 0, 1);
> + buf[cnt++] = BPF_ALU32_IMM(BPF_SUB, insn->dst_reg, (s32)base);
> + return cnt;
> +}
[ ... ]
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 70fd44a6e1c56..a24a2bab802b3 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
[ ... ]
> @@ -6661,6 +6697,11 @@ static int check_ptr_to_btf_access(struct bpf_verifier_env *env,
> if (ret < 0)
> return ret;
>
> + if (ret == PTR_TO_ARENA)
> + return check_arena_member_load(env, regs, value_regno, flag, tname, field_name);
> + if (atype == BPF_READ && value_regno >= 0)
> + env->insn_aux_data[env->insn_idx].non_arena_member = true;
[Severity: High]
Does this code miss setting the conflict flag for non-BTF pointers?
The verifier's save_aux_ptr_type() permits sharing an instruction across
branches where one path uses PTR_TO_BTF_ID and the other uses PTR_TO_MEM
(by merging them via allow_trust_mismatch).
If the PTR_TO_BTF_ID path reads an __arena member, check_ptr_to_btf_access()
sets aux->arena_member = true. However, when the PTR_TO_MEM path is
evaluated, check_mem_access() does not set aux->non_arena_member = true for
memory pointers.
> +
> if (ret != PTR_TO_BTF_ID) {
> /* just mark; */
>
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261012133711.4030594-1-memxor@gmail.com?part=3
next prev parent reply other threads:[~2026-10-12 14:00 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-12 13:36 [PATCH bpf-next v1 00/10] Fix some arena paper cuts Kumar Kartikeya Dwivedi
2026-10-12 13:36 ` [PATCH bpf-next v1 01/10] compiler_types: Add __arena and __nullable BTF type tag qualifiers Kumar Kartikeya Dwivedi
2026-10-12 13:36 ` [PATCH bpf-next v1 02/10] bpf: Recognize __nullable on pointer members of kernel structs Kumar Kartikeya Dwivedi
2026-10-12 13:54 ` sashiko-bot
2026-10-12 13:37 ` [PATCH bpf-next v1 03/10] bpf: Turn loads of __arena pointer members into arena pointers Kumar Kartikeya Dwivedi
2026-10-12 14:00 ` sashiko-bot [this message]
2026-10-12 14:27 ` bot+bpf-ci
2026-10-12 13:37 ` [PATCH bpf-next v1 04/10] selftests/bpf: Test __nullable pointer members Kumar Kartikeya Dwivedi
2026-10-12 14:27 ` bot+bpf-ci
2026-10-12 13:37 ` [PATCH bpf-next v1 05/10] selftests/bpf: Test __arena " Kumar Kartikeya Dwivedi
2026-10-12 14:27 ` bot+bpf-ci
2026-10-12 13:37 ` [PATCH bpf-next v1 06/10] libbpf: Bind the arena of an object to every program in it Kumar Kartikeya Dwivedi
2026-10-12 14:27 ` bot+bpf-ci
2026-10-12 13:37 ` [PATCH bpf-next v1 07/10] selftests/bpf: Test arena binding by libbpf Kumar Kartikeya Dwivedi
2026-10-12 13:44 ` sashiko-bot
2026-10-12 14:27 ` bot+bpf-ci
2026-10-12 13:37 ` [PATCH bpf-next v1 08/10] bpf: Set up the arena base only in functions that use it Kumar Kartikeya Dwivedi
2026-10-12 14:27 ` bot+bpf-ci
2026-10-12 13:37 ` [PATCH bpf-next v1 09/10] libbpf: Render the arena type tag with its address space Kumar Kartikeya Dwivedi
2026-10-12 13:37 ` [PATCH bpf-next v1 10/10] selftests/bpf: Test the address space rendering of the arena type tag Kumar Kartikeya Dwivedi
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=sashiko-outbox-168226@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=memxor@gmail.com \
--cc=sashiko-reviews@lists.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 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.