Re: [RFC PATCH bpf-next v1 04/11] bpf: Give the inlined bpf_loop a pad

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

On Wed Oct 28, 2026 at 2:10 AM CET, sashiko-bot wrote:
> [...]
> [Severity: High]
> Can this leave a live BPF_JMP32_A instruction targeting a dead caller landing
> pad that gets removed by bpf_opt_remove_dead_code(), leading to an
> out-of-bounds read in addrs[] or ctx->offset[] during JIT compilation?

Right: the pad of the caller is dead with a loop of no rounds, or with
an unwind_exit on a path the verifier never took, and the jump of the
inlined pad was left pointing into what the removal of dead code took
away. KASAN sees do_jit() read addrs[] past the end. The next version
gives the inlined loop a pad only when the verifier saw the pad of the
caller, with a test for the loop of no rounds.

> [...]
> [Severity: High]
> What happens if bpf_is_unwind_goto(&new_prog->insnsi[position + cnt]) is true,
> but pad is false (for example, when
> env->subprog_info[callback_subprogno].can_unwind is false, or when the
> caller's landing pad was not reached from this call site)?

The unwind_goto after the call becomes a no-op jump either way in the
next version, so it never follows the last insn of the loop.

> [...]