Re: [PATCH bpf-next v6 05/17] bpf: Introduce bpf register BPF_REG_PARAMS

[sashiko-bot@kernel.org]

Sashiko AI review found 1 potential issue(s):
- [Critical] Unvalidated BPF_REG_PARAMS instructions cause silent register aliasing and arbitrary kernel memory corruption on architectures lacking stack argument support.
--

commit 9b78142c31c81cff58a84123ee2833f9b935c211
Author: Yonghong Song <yonghong.song@linux.dev>

bpf: Introduce bpf register BPF_REG_PARAMS

This commit introduces BPF_REG_PARAMS as a dedicated BPF register for stack
argument accesses, occupying BPF register number 11 (R11). It shifts the
kernel-internal hidden register BPF_REG_AX to slot 12.

> diff --git a/include/linux/filter.h b/include/linux/filter.h
> index 1ec6d5ba64cc4..b77d0b06db6eb 100644
> --- a/include/linux/filter.h
> +++ b/include/linux/filter.h
> @@ -58,8 +58,9 @@ struct ctl_table_header;
>  #define BPF_REG_H	BPF_REG_9	/* hlen, callee-saved */
>  
>  /* Kernel hidden auxiliary/helper register. */
> -#define BPF_REG_AX		MAX_BPF_REG
> -#define MAX_BPF_EXT_REG		(MAX_BPF_REG + 1)
> +#define BPF_REG_PARAMS		MAX_BPF_REG

Does the introduction of BPF_REG_PARAMS without JIT-support validation allow
architectures lacking stack argument support (like ARM64, RISC-V, s390x) to
inadvertently use uninitialized JIT register mappings?

If the verifier doesn't gate BPF_REG_PARAMS usage behind a check like
bpf_jit_supports_stack_args(), could a crafted program trigger silent
register aliasing?

For example, if a program sets BPF_REG_1 to an arbitrary kernel address and
executes BPF_STX_MEM(BPF_DW, BPF_REG_PARAMS, BPF_REG_2, -8), the verifier may
allow it as a safe outgoing stack argument write. When the ARM64 JIT compiles
the instruction, it looks up index 11. If that index is uninitialized and
defaults to 0, it would emit a store using x0 (which is BPF_REG_1) as the
base pointer (e.g., STR x1, [x0, #-8]).

Could this write an arbitrary value into a controlled kernel address and
bypass verifier memory safety guarantees?

> +#define BPF_REG_AX		(MAX_BPF_REG + 1)
> +#define MAX_BPF_EXT_REG		(MAX_BPF_REG + 2)
>  #define MAX_BPF_JIT_REG		MAX_BPF_EXT_REG

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260419163316.731019-1-yonghong.song@linux.dev?part=5