Re: [PATCH bpf-next v9 07/23] bpf: Verify an unwind through landing pads and epilogues

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

On 10/8/26 10:57 AM, bot+bpf-ci@kernel.org wrote:
>> bpf: Verify an unwind through landing pads and epilogues
> TL;DR: In backtrack_insn(), if a landing pad directly follows a global call,
> the normal return may take the new pad branch, which doesn't clear R2, so a
> precise R2 could trigger verifier_bug() and -EFAULT.
>
>> diff --git a/kernel/bpf/backtrack.c b/kernel/bpf/backtrack.c
>> --- a/kernel/bpf/backtrack.c
>> +++ b/kernel/bpf/backtrack.c
> [ ... ]
>
>> @@ -434,6 +459,24 @@ static int backtrack_insn(struct bpf_verifier_env *env, int idx, int subseq_idx,
>>   					return -EFAULT;
>>   			}
>>
>> +			if (bpf_exc_pad_of_call(env, idx) == subseq_idx) {
>> +				/*
>> +				 * We came from the landing pad of a call to a
>> +				 * global subprog, branched to from the state
>> +				 * the call returns in: as on its return, no
>> +				 * frame was entered here. The call clobbered
>> +				 * r0-r5; r6-r9 and the stack are the caller's
>> +				 * own and keep going back from here.
>> +				 */
>> +				bt_clear_reg(bt, BPF_REG_0);
>> +				if (bt_reg_mask(bt) & BPF_REGMASK_ARGS) {
>> +					verifier_bug(env, "landing pad unexpected regs %x",
>> +						     bt_reg_mask(bt));
>> +					return -EFAULT;
>> +				}
>> +				return 0;
>> +			}
>> +
>>   			/* callx calls static subprogs only */
>>   			if (subprog >= 0 && bpf_subprog_is_global(env, subprog)) {
>>   				/* check that jump history doesn't have any
> [ ... ]
>
> Is comparing subseq_idx with the call's pad enough to tell that the walk
> came over the pad edge?

Not sure. For global subprog, next insn could be a follow-up or could be
a landing pad, as you analysed below.

In such cases, for global subprog, it will go to non-landing pad first
and will return. This will cause problems as global subprog and landing
pad connection got lost. This is a bug and will fix it in the next revision.
Basically, we can remove "if (bpf_exc_pad_of_call(env, idx) == subseq_idx)"
and deal with it under "if (subprog >= 0 && bpf_subprog_is_global(env, subprog))".

>
> bpf_exc_check_info() accepts a record [c, c+1) -> c+1, because its pad check
> treats end_off as exclusive.  With that layout the pad is the insn right
> after the call:
>
>      c:     call global_subprog
>      c + 1: pad
>
> In that case the normal return of the global call also has subseq_idx ==
> idx + 1 == pad, so it now goes through the new pad branch instead of the
> global call branch below it.
>
> The pad branch clears only BPF_REG_0, while the global call branch also
> clears R2.  For a global subprog that returns in the R0:R2 pair
> (bpf_ret_reg_pair()), the normal return path really does define R2 as a
> scalar.
>
> If precision on R2 reaches the call insn over that edge, for example from
> propagate_precision() when the path is pruned against a checkpoint where R2
> is precise, the pad branch finds R2 still set in the mask:
>
>      bt_clear_reg(bt, BPF_REG_0);
>      if (bt_reg_mask(bt) & BPF_REGMASK_ARGS) {
>          verifier_bug(env, "landing pad unexpected regs %x", ...);
>          return -EFAULT;
>      }
>
> That fires verifier_bug(), which is a WARN_ONCE under CONFIG_DEBUG_KERNEL
> plus -EFAULT, rather than handling the edge as a normal global return as
> happened before this patch.
>
> Should the pad branch also clear R2, which is NOT_INIT on the real pad path
> anyway, or should it apply only when subseq_idx != idx + 1?
>
> I did not find a later patch in the series that touches backtrack_insn()
> again to address this.
>
>
> ---
> 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/37747693645