Re: [PATCH bpf-next v5 05/11] bpf: Account R2 of register-pair returns in live register analysis

On 8/13/26 6:50 PM, [email protected] wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
>
> Pre-existing issues:
> - [High] Static (non-global) BPF subprograms returning a register pair are functionally broken because the verifier does not propagate R2 back to the caller frame.
> --
>
> --- Patch [5]: [PATCH bpf-next v5 05/11] bpf: Account R2 of register-pair returns in live register analysis ---
> commit 35ab629244a73b2ad2baa7b7f0fd5b365c1b35e9
> Author: Yonghong Song <[email protected]>
>
> bpf: Account R2 of register-pair returns in live register analysis
>
> This commit updates the live register analysis to correctly mark R2 as read
> at the BPF_EXIT of a subprogram that returns a register pair. This prevents
> R2 from being considered dead and pruned incorrectly.
>
>> diff --git a/kernel/bpf/liveness.c b/kernel/bpf/liveness.c
>> index 74fc4b3f80d6e..71f998c6eb888 100644
>> --- a/kernel/bpf/liveness.c
>> +++ b/kernel/bpf/liveness.c
> [ ... ]
>> @@ -2191,7 +2193,7 @@ static void compute_insn_live_regs(struct bpf_verifier_env *env,
>>   			break;
>>   		case BPF_EXIT:
>>   			def = 0;
>> -			use = r0;
>> +			use = ret_reg_pair ? (r0 | r2) : r0;
>>   			break;
> [Severity: High]
> This is a pre-existing issue, and wasn't introduced by this patch, but while
> we are fixing liveness tracking for register-pair returns here, is the
> propagation of R2 back to the caller missing in the verifier?
>
> Looking at prepare_func_exit() in kernel/bpf/verifier.c:
>
>      } else {
>          /* return to the caller whatever r0 had in the callee */
>          caller->regs[BPF_REG_0] = *r0;
>      }
>
> When a static BPF subprogram returning a 16-byte struct is called,
> check_func_call() sets all caller-saved registers (including R2) to NOT_INIT.
> When the callee exits, it seems we only copy BPF_REG_0 back to the
> caller's state, leaving BPF_REG_2 as NOT_INIT.
>
> If the caller attempts to read the second half of the returned struct in R2,
> will the verifier reject it with an 'R2 !read_ok' error?

We should be okay here. The next patch will actually introducing return value
R2 in various places.

>