Re: [PATCH bpf-next v5 05/10] bpf, x86: refactor BPF_ST management in do_jit

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The `emit_st()` helper absorbs `Arg 6` pseudo-store and `BPF_REG_PARAMS` translation, causing invalid KASAN instrumentation for BPF_ST instructions.
--

--- Patch [5]: [PATCH bpf-next v5 05/10] bpf, x86: refactor BPF_ST management in do_jit ---
commit b88dd49e34d6904772392eec8dfdeba3542805c4
Author: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>

bpf, x86: refactor BPF_ST management in do_jit

This commit extracts the x86-64 BPF_ST instruction emission logic into a single
emit_st() helper function. It is intended to prepare for KASAN checks being
inserted before memory loads and stores.

> diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
> index d35f58350d710..959fcaa0cde9a 100644
> --- a/arch/x86/net/bpf_jit_comp.c
> +++ b/arch/x86/net/bpf_jit_comp.c
> @@ -1410,6 +1410,64 @@ static void emit_st_index(u8 **pprog, u32 size, u32 dst_reg, u32 index_reg, int
>  	*pprog = prog;
>  }
>  
> +static void emit_st(u8 **pprog, struct bpf_insn *insn, int dst_reg,
> +		    s32 outgoing_arg_base, u16 outgoing_rsp)
> +{
> +	s32 imm32 = insn->imm;
> +	u8 *prog = *pprog;
> +	s32 insn_off;
> +
> +	switch (BPF_SIZE(insn->code)) {
[ ... ]
> +	case BPF_DW:
> +		if (dst_reg == BPF_REG_PARAMS && insn->off == -8) {
> +			/* Arg 6: store immediate in r9 register */
> +			emit_mov_imm64(&prog, X86_REG_R9, imm32 >> 31,
> +				       (u32)imm32);
> +			*pprog = prog;
> +			return;
> +		}
> +		EMIT2(add_1mod(0x48, dst_reg), 0xC7);
> +		break;
> +	}
> +
> +	insn_off = insn->off;
> +	if (dst_reg == BPF_REG_PARAMS) {
> +		/*
> +		 * Args 7+: reverse BPF negative offsets to
> +		 * x86 positive rsp offsets.
> +		 * BPF off=-16 → [rsp+0], off=-24 → [rsp+8], ...
> +		 */
> +		insn_off = outgoing_arg_base - outgoing_rsp -
> +			insn_off - 16;
> +		dst_reg = BPF_REG_FP;
> +	}

[Severity: High]
Does hiding the BPF_REG_PARAMS translation inside emit_st() conflict with the
stated goal of adding KASAN instrumentation before the call?

If KASAN checks are inserted in do_jit() before emit_st() is called, wouldn't
they attempt to instrument Arg 6 (which uses register r9, not memory)?

Additionally, wouldn't any KASAN checks added before this helper use the raw
BPF_REG_PARAMS pseudo-register before it is translated to BPF_REG_FP, causing
instrumentation against an unmapped register (which evaluates to rax)?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260709-kasan-v5-0-1c64af8e4e1e@bootlin.com?part=5