Re: [RFC PATCH bpf-next v1 03/11] bpf: Let a callback unwind into the pad of its helper

[Kumar Kartikeya Dwivedi <memxor@gmail.com>]

On Wed Oct 28, 2026 at 2:31 AM CET, sashiko-bot wrote:
> [...]
> [Severity: Medium]
> What happens when unwind_goto follows a call to bpf_loop() that gets inlined
> by bpf_optimize_bpf_loop() -> inline_bpf_loop(), but the callback does not
> unwind (!env->subprog_info[subprog].can_unwind)?

The next version turns the unwind_goto after the call of bpf_loop() into
a no-op jump whether or not the inlined loop gets a pad, so it never
follows the last insn of the loop, and the loop gets a pad only when the
verifier saw the pad of the caller: with a loop of no rounds that pad is
dead and goes with the dead code.

> [...]
> [Severity: High]
> Can a callback with a 9..16 byte BTF return type clobber the caller's R2
> argument register when it exits via unwind_exit?

Right. The pad of a helper carries r0 alone, so a callback hands over r0
alone in the next version, whatever its prototype says.

> [...]
> [Severity: Medium]
> Can revisiting the call instruction with state->unwound set trigger
> verifier_bug_if() in do_check()'s precomputed constant register check?

Right. The revisit carries the r0 of the callback, so r0 is no constant
of such an insn: bpf_compute_const_regs() skips it there in the next
version, as liveness has it live there already.

> [...]