Re: [PATCH bpf-next v5 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] The BPF JIT KASAN integration on x86-64 fails to preserve caller-saved registers `r10` and `r11` across calls to KASAN functions, corrupting BPF internal state.
--

--- Patch [7]: [PATCH bpf-next v5 07/10] bpf, x86: enable KASAN for JITed programs on x86 ---
commit ecf3ad3bc8d5ddd31f31891c28722d7d1b08f230
Author: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>

bpf, x86: enable KASAN for JITed programs on x86

This commit marks x86 as supporting KASAN checks in JITed programs. It enables 
the corresponding JIT compiler to insert checks on 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]
Enabling this option exposes a register corruption regression in the underlying
KASAN JIT implementation.

Looking at how emit_kasan_check() is implemented in
arch/x86/net/bpf_jit_comp.c, it saves most caller-saved registers but
explicitly skips r10 and r11:

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

	...
	/* call kasan_func */
	if (emit_call(&prog, kasan_func, ip))
		return -ERANGE;
	...
}

However, during atomic fetch operations, do_jit() relies on BPF_REG_AX
(which maps to r10) holding live state across the emit_kasan_check() call:

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

Since __asan_store* is a standard C function, it can clobber r10
(BPF_REG_AX) according to the System V AMD64 ABI.

Could the omission of r10 and r11 in emit_kasan_check() lead to corrupted
internal BPF state when the verifier expects BPF_REG_AX to be preserved?

>  	select HAVE_EFFICIENT_UNALIGNED_ACCESS
>  	select HAVE_EISA			if X86_32
>  	select HAVE_EXIT_THREAD

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