> diff --git a/arch/powerpc/net/bpf_jit_comp64.c
> b/arch/powerpc/net/bpf_jit_comp64.c
> index c284a12fce6e..98780a15fc69 100644
> --- a/arch/powerpc/net/bpf_jit_comp64.c
> +++ b/arch/powerpc/net/bpf_jit_comp64.c
[ ... ]
> @@ -125,9 +149,19 @@ int bpf_jit_stack_tailcallinfo_offset(struct
> codegen_context *ctx)
>
> static int bpf_jit_stack_offsetof(struct codegen_context *ctx, int reg)
> {
> - if (reg >= BPF_PPC_NVR_MIN && reg < 32)
> + int min_valid_nvreg = BPF_PPC_NVR_MIN;
> + /* Default frame size for all cases except exception boundary */
> + int frame_nvr_size = BPF_PPC_STACKFRAME;
> +
> + /* Consider all nv regs for handling exceptions */
> + if (ctx->exception_boundary || ctx->exception_cb) {
> + min_valid_nvreg = _R14;
> + frame_nvr_size = BPF_PPC_EXC_STACKFRAME;
> + }
> +
> + if (reg >= min_valid_nvreg && reg < 32)
> return (bpf_has_stack_frame(ctx) ?
> - (BPF_PPC_STACKFRAME + ctx->stack_size) : 0)
> + (frame_nvr_size + ctx->stack_size) : 0)
> - (8 * (32 - reg)) - BPF_PPC_TAILCALL;
For the redzone case (no stack frame) with exception_boundary, this
formula computes R23 at offset -80 and R24 at offset -72 from R1.
However, bpf_stf_barrier() uses hardcoded offsets -80(1) and -72(1) to
temporarily save R21 and R22 during STF barrier execution:
asm (
" bpf_stf_barrier: ;"
" std 21,-80(1) ;"
" std 22,-72(1) ;"
" sync ;"
" ld 21,-80(1) ;"
" ld 22,-72(1) ;"
...
);
When an exception_boundary program without its own stack frame executes a
memory load that triggers STF_BARRIER_FALLBACK, can bpf_stf_barrier()
corrupt the saved R23 and R24 values? The hardcoded offsets would overlap
with the extended NVR save area.
If exception_cb later restores these registers, it would get R21/R22 values
instead of the original R23/R24 values.
[ ... ]
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/21265643939