Re: [PATCH bpf-next v3 07/10] bpf, x86: enable KASAN for JITed programs on x86

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] emit_kasan_check() fails to preserve the caller-saved r10 register (BPF_REG_AX), causing BPF program state corruption and kernel crashes during BPF_ATOMIC_FETCH operations.
--

commit 9b578f89250bc8a04722f64b0dbcf3e863ff5692
Author: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>

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 KASAN checks for
JITed BPF programs here exposes a pre-existing issue in the x86 JIT
compiler during atomic operations.

When handling BPF_ATOMIC_FETCH with BPF_REG_0 as a source or destination,
do_jit() saves BPF_REG_0 into BPF_REG_AX before emitting the KASAN check:

arch/x86/net/bpf_jit_comp.c:do_jit() {
    ...
    /* Will need RAX as a CMPXCHG operand so save R0 */
    emit_mov_reg(&prog, true, BPF_REG_AX, BPF_REG_0);
    ...
    if (!bpf_atomic_is_load_store(insn)) {
        err = emit_kasan_check(env, &prog, real_dst_reg,
                               insn, ip, false,
                               accesses_stack_only);
    ...
}

In the x86 JIT, BPF_REG_AX maps to the r10 register. Looking at
emit_kasan_check(), it manually pushes caller-saved registers before calling
the KASAN C function:

arch/x86/net/bpf_jit_comp.c:emit_kasan_check() {
    ...
    /* Save rdi */
    EMIT1(0x57);
    /* Save r8 */
    EMIT2(0x41, 0x50);
    /* Save r9 */
    EMIT2(0x41, 0x51);
    ...
}

This sequence fails to save r10 and r11. According to the System V AMD64 ABI,
r10 is caller-saved, meaning the KASAN C function is free to clobber it.

When emit_kasan_check() returns, BPF_REG_AX (r10) might contain garbage. 

Could this cause subsequent memory accesses using real_dst_reg to dereference
a garbage pointer if BPF_REG_0 was the destination?

Does this also corrupt the BPF program state when BPF_REG_0 is later restored
from BPF_REG_AX after the CMPXCHG loop?

>  	select HAVE_EFFICIENT_UNALIGNED_ACCESS
>  	select HAVE_EISA			if X86_32
>  	select HAVE_EXIT_THREAD

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260701-kasan-v3-0-bd09bb942d86@bootlin.com?part=7