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

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

[Yonghong Song]

On 4/19/26 10:06 AM, sashiko-bot@kernel.org wrote:
> 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?

See patch 'bpf: Enable r11 based insns'. r11 based insns will be
rejected earlier in check_and_resolve_insns(). And before this patch,
bpf function support is done, jit support is disabled,
so we are fine.

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

This is not an issue. All potential r11 related issues are resolved
(as far as I know) before "bpf: Enable r11 based insns".

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