Re: [RFC PATCH bpf-next v1 06/16] bpf: Support special fields in typed arena objects

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] bpf: bpf_kptr_xchg allows user-space to forge kernel pointers via typed arena memory
- [High] bpf: bpf_kptr_xchg on arena pointers causes kernel panic on archs lacking inline support
--

commit 2d0dbe5c6fd18e1e3096285d4ab48687f876b4ce
Author: Kumar Kartikeya Dwivedi <memxor@gmail.com>

bpf: Support special fields in typed arena objects

This commit allows bpf_kptr_xchg() to take a pointer to a kptr field of a
typed arena object. It modifies the verifier to permit objects in arena
memory to own references to kernel objects and program-allocated objects.

> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 75697e52a2df6..f854d8419fff0 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
[ ... ]
> @@ -8063,7 +8063,7 @@ static int process_kptr_func(struct bpf_verifier_env *env, int regno,
>  	struct btf_record *rec;
>  	u32 kptr_off;
>  
> -	if (type_is_ptr_alloc_obj(reg->type)) {
> +	if (type_is_ptr_alloc_obj(reg->type) || type_is_typed_arena_obj(reg->type)) {
>  		rec = reg_btf_record(reg);

[Severity: Critical]
Does this allow user-space to forge kernel pointers?

Because arena memory (BPF_MAP_TYPE_ARENA) is inherently shared between the
kernel and user-space, it can be mmapped with PROT_READ and PROT_WRITE.
Furthermore, arena maps lack a map-level btf_record (it is NULL), which
bypasses the standard check in bpf_map_mmap() that forbids mmapping maps
containing special fields.

Could a malicious user-space process mmap the arena, write an arbitrary
64-bit value to the offset of the kptr field, and then have the BPF program
call bpf_kptr_xchg() to read this user-supplied value? The verifier would
unconditionally track the returned value as a trusted kernel pointer.

Could this forged pointer then be dereferenced or passed to bpf_obj_drop(),
leading to memory corruption or KASLR bypass?

>  	} else { /* PTR_TO_MAP_VALUE */
>  		map_ptr = reg->map_ptr;
[ ... ]
> @@ -8834,6 +8834,7 @@ static const struct bpf_reg_types kptr_xchg_dest_types = {
>  		PTR_TO_BTF_ID | MEM_ALLOC,
>  		PTR_TO_BTF_ID | MEM_ALLOC | NON_OWN_REF,
>  		PTR_TO_BTF_ID | MEM_ALLOC | NON_OWN_REF | MEM_RCU,
> +		PTR_TO_BTF_ID | MEM_ARENA,

[Severity: High]
Could this cause a kernel panic on architectures that lack inline support
for ptr_xchg?

On architectures that support arenas but do not override
bpf_jit_supports_ptr_xchg() to return true (e.g., PowerPC and s390x), the JIT
will fall back to calling the bpf_kptr_xchg() C kernel helper.

The bpf_kptr_xchg() helper uses the raw xchg() macro on the provided pointer,
which resides in demand-paged arena memory:

kernel/bpf/helpers.c:bpf_kptr_xchg() {
    ...
    return xchg(kptr, (unsigned long)ptr);
}

If the accessed arena page is unmapped, a kernel page fault occurs. Because
bpf_arena_handle_page_fault() is only wired up in the architecture-specific
fault handlers for arm64 and x86, it is completely ignored on PowerPC and
s390x.

Since the xchg() macro lacks an exception table entry inside the helper,
wouldn't an unmapped arena page result in an unhandled fault and a direct
kernel panic?

>  	}
>  };

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260926233503.3114147-1-memxor@gmail.com?part=6