Re: [PATCH bpf-next v8 2/9] bpf: Introduce global percpu data

[Leon Hwang <leon.hwang@linux.dev>]

On 29/6/26 23:50, sashiko-bot@kernel.org wrote:
[...]
>> +			/*
>> +			 * Reuse the original ld_imm64 insn, and add one
>> +			 * mov64_percpu_reg insn.
>> +			 */
>> +
>> +			insn_buf[0] = insn[1];
>> +			insn_buf[1] = BPF_MOV64_PERCPU_REG(insn->dst_reg, insn->dst_reg);
> 
> [Severity: High]
> This is a pre-existing issue, but does the BPF interpreter properly handle
> BPF_MOV64_PERCPU_REG?
> 
> The verifier correctly checks bpf_jit_supports_percpu_insn() before inserting
> this instruction. However, if JIT compilation fails later (e.g., due to memory
> limits) and the system falls back to the interpreter, what happens to this
> instruction?
> 
> Looking at ___bpf_prog_run() in kernel/bpf/core.c:
> 
>     ALU64_MOV_X:
>         switch (OFF) {
>         case 0:
>             DST = SRC;
>             break;
> 
> The interpreter appears to silently ignore OFF == BPF_ADDR_PERCPU, essentially
> treating it as a no-op or standard move.
> 
> Would this leak the raw __percpu pointer (which is often a small integer
> offset on architectures like x86) into subsequent memory access instructions?
> While this patch didn't introduce the interpreter fallback behavior, it seems
> to expand the surface area by allowing direct read/write accesses to arbitrary
> percpu arrays. Could this lead to out-of-bounds memory accesses if JIT fails?
> 

Correct. It will trigger a page fault.

The issue will be fixed by
https://lore.kernel.org/bpf/20260626154330.33619-1-leon.hwang@linux.dev/.

Thanks,
Leon