Re: [PATCH v4 bpf-next 1/6] bpf: Add unwind_goto and unwind_exit insns

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

On Tue, Oct 20, 2026 at 11:57 AM sashiko-bot@kernel.org <sashiko-bot@kernel.org> wrote:
>> +			if (!aux_data[i + 1].seen) {
>> +				memcpy(insn + 1, &trap, sizeof(trap));
>> +				aux_data[i + 1].seen = env->pass_cnt;
>> +			}
>
> [Severity: High]
> When bpf_opt_hard_wire_dead_code_branches() overwrites insn + 1 with trap and
> marks aux_data[i + 1].seen = env->pass_cnt, could stale flags in
> aux_data[i + 1] corrupt the trap instruction or trigger a verifier bug?

No. That verifier_bug_if() needs bpf_jit_needs_zext(), and it's false
on x86-64 and arm64, the only JITs with bpf_jit_supports_unwind().
needs_zext and arena_scalar need an arena, and arena needs CAP_PERFMON.
Then bypass_spec_v1 is true, there is no speculative walk of i + 1,
and they cannot be set on an insn that wasn't seen.

> Also, what happens if the call and unwind_goto at insn i are themselves in
> dead code (!aux_data[i].seen), but jump to a shared landing pad that was
> reached from another call (aux_data[i + 1 + insn->off].seen)? Because
> aux_data[i].seen is not checked here, insn + 1 is overwritten with trap and
> marked seen, so bpf_opt_remove_dead_code() removes the dead call and
> unwind_goto while leaving an orphaned goto pc-1 in the program (and any
> later live conditional jump with untaken target i + 1 can no longer see
> !aux_data[i + 1].seen).
>
> Should this check aux_data[i].seen before handling unwind_goto, and clear
> zext_dst, needs_zext, and arena_scalar on aux_data[i + 1] when writing trap?

Not a bug. It's one extra 'goto pc-1' that nothing can reach. A live
cond jump to it is never taken, otherwise i + 1 would have been seen.

>> +	if (!bpf_jit_supports_unwind()) {
>> +		verbose(env, "JIT does not support unwinding\n");
>> +		return -ENOTSUPP;
>> +	}
>
> [Severity: Medium]
> Should check_unwind_insns() also reject programs when
> !env->prog->jit_requested or bpf_prog_is_offloaded(env->prog->aux)?

yeah. Only netdevsim gets there, nfp rejects the opcode in
nfp_verify_insn(), and nothing runs such a prog, so it's just a wrong
xlated dump. Will reject offloaded progs in check_unwind_insns() in v5.

> Similarly, when CONFIG_BPF_JIT_ALWAYS_ON is disabled and bpf_jit_enable is 0,
> checking !env->prog->jit_requested in check_unwind_insns() (like
> require_callx_jit() does) would reject unwinding before passes such as
> bpf_compute_subprog_ret_regs() that gate on env->prog->jit_requested.

Not a bug. jit_required is set, so bpf_fixup_call_args() rejects the
prog at the end of verification. It's only a matter of when.