Re: [PATCH bpf-next 07/20] bpf: Refuse exception cleanup shapes bpf_throw() cannot dispatch

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

On 9/18/26 9:57 PM, Alexei Starovoitov wrote:
> On Wed, Sep 16, 2026 at 10:57 PM Yonghong Song <yonghong.song@linux.dev> wrote:
>> diff --git a/kernel/bpf/exception.c b/kernel/bpf/exception.c
>> index dfe9c2a9ce7d..b2bf831242b8 100644
>> --- a/kernel/bpf/exception.c
>> +++ b/kernel/bpf/exception.c
> [...]
>
>> +static enum cleanup_insn_kind cleanup_classify(struct bpf_verifier_env *env, u32 i,
>> +					       int *next, int *target)
>> +{
>> +	struct bpf_insn *insn = &env->prog->insnsi[i];
>> +	u8 class = BPF_CLASS(insn->code);
>> +
>> +	*next = i + 1;
>> +	*target = -1;
>> +
>> +	if (insn->code == (BPF_LD | BPF_IMM | BPF_DW)) {
>> +		*next = i + 2;
>> +		return CLEANUP_INSN_PLAIN;
>> +	}
>> +	if (class != BPF_JMP && class != BPF_JMP32)
>> +		return CLEANUP_INSN_PLAIN;
> robot voice:
>
> LD_ABS/LD_IND is not plain. bpf_check_cfg() treats it as an abnormal
> return and gen_ld_abs() later patches in a real "r0 = 0; exit" for the
> failed load. With this classification a pad in a tc prog that keeps
> skb in r6 and does an ld_abs passes t
> he "reaches no exit" check,
> cleanup_check_pad_insn() doesn't look at it, and check_ld_abs() only
> wants no locks/refs held at that point. At run time a failed load runs
> the subprog epilogue on the walker's stack: callee regs get popped
> from arch_bpf_run_cleanup_pad()'s frame, leave/ret with rbp == the
> unwinding frame goes straight back into the BPF caller with garbage
> in rbx/r13-r15, and the rest of bpf_throw() is abandoned.
> Treat it like BPF_EXIT here or refuse it in a pad body like tail call.

Yes, this is an issue. For insns in landing pad, we should not allow
LD_ABS/LD_IND since they will have a hidden return. So the above suggestion
to refuse it in a pad body is correct.