Re: [PATCH bpf-next v5 06/16] bpf: Limit the scope of BPF_REG_PARAMS usage

[Yonghong Song <yonghong.song@linux.dev>]

On 4/16/26 9:30 PM, bot+bpf-ci@kernel.org wrote:
>> diff --git a/kernel/bpf/const_fold.c b/kernel/bpf/const_fold.c
>> index db73c4740b1e..09db7fdb370f 100644
>> --- a/kernel/bpf/const_fold.c
>> +++ b/kernel/bpf/const_fold.c
> [ ... ]
>
>> diff --git a/kernel/bpf/liveness.c b/kernel/bpf/liveness.c
>> index 1fb4c511db5a..993d7e543e9f 100644
>> --- a/kernel/bpf/liveness.c
>> +++ b/kernel/bpf/liveness.c
> [ ... ]
>
>> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
>> index ff0c55d80311..f25a56cfabac 100644
>> --- a/kernel/bpf/verifier.c
>> +++ b/kernel/bpf/verifier.c
>> @@ -18487,13 +18487,22 @@ static int check_and_resolve_insns(struct bpf_verifier_env *env)
>>   		return err;
>>
>>   	for (i = 0; i < insn_cnt; i++, insn++) {
>> +		u8 class = BPF_CLASS(insn->code);
>> +		u8 mode = BPF_MODE(insn->code);
>> +
>>   		if (insn->dst_reg >= MAX_BPF_REG) {
>> -			verbose(env, "R%d is invalid\n", insn->dst_reg);
>> -			return -EINVAL;
>> +			if (insn->dst_reg != BPF_REG_PARAMS ||
>> +			    !((class == BPF_ST  || class == BPF_STX) && mode == BPF_MEM)) {
>> +				verbose(env, "R%d is invalid\n", insn->dst_reg);
>> +				return -EINVAL;
>> +			}
>>   		}
>>   		if (insn->src_reg >= MAX_BPF_REG) {
>> -			verbose(env, "R%d is invalid\n", insn->src_reg);
>> -			return -EINVAL;
>> +			if (insn->src_reg != BPF_REG_PARAMS || class != BPF_LDX ||
>> +			    mode != BPF_MEM) {
>> +				verbose(env, "R%d is invalid\n", insn->src_reg);
>> +				return -EINVAL;
>> +			}
>>   		}
>>   		if (insn[0].code == (BPF_LD | BPF_IMM | BPF_DW)) {
>>   			struct bpf_insn_aux_data *aux;
> Can these instructions with BPF_REG_PARAMS trigger out-of-bounds accesses
> in subsequent verification functions? The regs array in struct
> bpf_func_state is declared as regs[MAX_BPF_REG] with MAX_BPF_REG=11,
> giving valid indices 0-10.
>
> When instructions with src_reg=BPF_REG_PARAMS (11) reach check_load_mem():
>
> kernel/bpf/verifier.c:check_load_mem() {
>      ...
>      src_reg_type = regs[insn->src_reg].type;
>      ...
> }
>
> This performs regs[11] which is one past the end of the array.
>
> Similarly, when instructions with dst_reg=BPF_REG_PARAMS reach
> __check_reg_arg():
>
> kernel/bpf/verifier.c:__check_reg_arg() {
>      ...
>      reg = &regs[regno];
>      ...
> }
>
> The commit message states "array-based register tracking indexed by
> register number would cause out-of-bounds accesses. So do early return
> if needed." However, the patch adds early returns in const_fold.c and
> liveness.c but not in the main verification path functions like
> check_load_mem() or __check_reg_arg().
>
> The fix appears to arrive in subsequent commit 212295359353 ("bpf:
> Support stack arguments for bpf functions"). Between this commit and
> that fix, could user-provided BPF programs with BPF_REG_PARAMS
> instructions trigger out-of-bounds memory access in the kernel verifier?

You are right, this patch should be after "bpf: Support stack arguments
for bpf functions" to avoid such issues.

>
> This commit also lacks a Fixes: tag. The suggested tag would be:
>
> Fixes: 595885eced33 ("bpf: Introduce bpf register BPF_REG_PARAMS")
>
>
> ---
> 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/24546989054