Re: [PATCH bpf-next v6 5/9] bpf, x86: enable KASAN for JITed programs on x86

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The x86 BPF JIT KASAN instrumentation fails to save R10 and R11 across calls to KASAN helpers, leading to arbitrary memory corruption when BPF_REG_AX is used as an address or value register.
--

--- Patch [5]: [PATCH bpf-next v6 5/9] bpf, x86: enable KASAN for JITed programs on x86 ---
commit d7d5cc9dc7fbffd1005cd390c1a9b1a31a2025be
Author: Alexis Lothoré (eBPF Foundation) <[email protected]>

bpf, x86: enable KASAN for JITed programs on x86

Mark x86 as supporting KASAN checks in JITed programs so that the
corresponding JIT compiler inserts checks on the translated
instructions.

> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index bdad90f210e4b..705a9ab85f3a9 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -233,6 +233,7 @@ config X86
>  	select HAVE_SAMPLE_FTRACE_DIRECT	if X86_64
>  	select HAVE_SAMPLE_FTRACE_DIRECT_MULTI	if X86_64
>  	select HAVE_EBPF_JIT
> +	select HAVE_EBPF_JIT_KASAN		if X86_64

[Severity: High]
This isn't a bug introduced by this patch, but enabling this config exposes
a pre-existing ABI violation in the x86 BPF JIT.

When a BPF program uses BPF_REG_0 as an address for an operation, the JIT
moves BPF_REG_0 to BPF_REG_AX (which maps to x86 register R10). It then
calls a C KASAN helper like __asan_store8 via emit_kasan_check().

In arch/x86/net/bpf_jit_comp.c:do_jit():

                emit_mov_reg(&prog, true, BPF_REG_AX, BPF_REG_0);
                if (src_reg == BPF_REG_0)
                    real_src_reg = BPF_REG_AX;
                ...
                err = emit_kasan_check(env, &prog, real_dst_reg,
                                       insn, ip, true);

However, emit_kasan_check() explicitly skips saving R10 and R11:

arch/x86/net/bpf_jit_comp.c:emit_kasan_check() {
    /*
     * SystemV ABI states that we should also save r10/r11, but in
     * practice those registers are _not_ used by the limited set of
     * kasan helpers we are calling here, so that's fine not to save those.
     */
}

Since R10 and R11 are caller-saved scratch registers in the System V AMD64
ABI, can the C compiler clobber R10 during the KASAN helper execution
(depending on the compiler version or optimization)?

If R10 is clobbered, won't the JITed code subsequently use the corrupted
register as a memory address, leading to arbitrary memory corruption?

>  	select HAVE_EFFICIENT_UNALIGNED_ACCESS
>  	select HAVE_EISA			if X86_32
>  	select HAVE_EXIT_THREAD

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=5