Re: [PATCH bpf-next 08/20] bpf: Walk the exception unwind in the verifier

["Alexei Starovoitov" <alexei.starovoitov@gmail.com>]

On Wed, Sep 16, 2026 at 10:57 PM Yonghong Song <yonghong.song@linux.dev> wrote:
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 9cbdb8339701..a3b34ded1392 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c

[...]

> +static int unwind_step(struct bpf_verifier_env *env, u32 callsite, int *insn_idx)
> +{
> +	struct bpf_verifier_state *state = env->cur_state;
> +
> +	state->unwinding = true;
> +	for (;;) {
> +		int pad = bpf_cleanup_pad_of_call(env, callsite);
> +
> +		if (pad >= 0) {
> +			unwind_enter_pad(env);
> +			*insn_idx = pad;
> +			return INSN_IDX_UPDATED;
> +		}
> +		if (!state->curframe)
> +			return unwind_finish(env);
> +		callsite = unwind_pop_frame(env);
> +	}
> +}

robot voice:

mark_chain_precision() doesn't know about this edge. The jmp history
gets (bpf_throw in frame N+k) -> (pad in frame N), or (resume in N+1)
-> (pad in N), with no BPF_EXIT in between, and backtrack_insn() only
switches frames on E
XIT and pseudo calls. So bt->frame stays at N
while it walks the callee's insns backwards. If the callee wrote its
own r6 the request for the caller's r6 is cleared there, the caller's
def of r6 is never marked precise, and a later state with a different
r6 is pruned at the call site checkpoint even though the pad does
r10 + r6 with it. If the callee didn't touch r6 the walk reaches the
static call insn with r6 still set and hits
verifier_bug("static subprog unexpected regs"). For a throwing global
subprog it's verifier_bug_if(idx + 1 != subseq_idx) right away.
The unwind transition needs its own jmp history flag and
backtrack_insn() has to bt_subprog_enter() once per popped frame,
like it does for BPF_EXIT.
Pls add a test that does a variable offset stack access in a pad
with the offset coming from r6-r9 set before the throwing call.

> +static int process_cleanup_resume(struct bpf_verifier_env *env, int *insn_idx)
> +{
> +	struct bpf_verifier_state *state = env->cur_
state;
> +
> +	/* A pad entered by ordinary control flow. */
> +	if (!state->unwinding) {
> +		verbose(env,
> +			"bpf_unwind_resume() at insn %d reached without an exception in flight\n",
> +			*insn_idx);
> +		return -EINVAL;
> +	}
> +	if (!state->curframe)
> +		return unwind_finish(env);
> +	return unwind_step(env, unwind_pop_frame(env), insn_idx);
> +}

unwinding is one bit for the whole state, so once a throw happened a
bpf_unwind_resume() is accepted in any frame, not only in the frame
whose pad the walker dispatched. The in_pad rule from patch 7 doesn't
close it: take subprog S that never throws, has its own record, and
whose pad is just "call bpf_unwind_resume" reachable by a plain branch
from S's entry. F's pad does "call S" and S branches into its pad.
Here the verifier pops S, finds no pad for the "call S" site, pops F
and finishes, so whatever follows "call S" in F's pad is never walked
in this state. On x86 S's resume is a bare ret, so at run time it


returns into F's pad right after "call S" and keeps executing it with
S's leftover registers. On arm64 br x23 ends F's pad early instead.
Remember the frame unwind_step() entered the pad in and reject
bpf_unwind_resume() when curframe doesn't match.

pw-bot: cr