Re: [PATCH bpf-next v7 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:
- [High] Caller-saved register R10 (BPF_REG_AX) is clobbered by KASAN checks during BPF atomic fetch operations and constant blinding, causing silent memory corruption.
--

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

bpf, x86: enable KASAN for JITed programs on x86

This commit marks x86 as supporting KASAN checks in JITed programs, causing
the JIT compiler to insert checks on translated instructions.

> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 48ccc3e6059d0..745890d91e99a 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -234,6 +234,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]
Does enabling this feature expose a register clobbering issue in how KASAN
checks are emitted?

Looking at emit_kasan_check() in arch/x86/net/bpf_jit_comp.c, it deliberately
skips saving R10 (which is mapped to BPF_REG_AX) before calling the KASAN
helper:

	/*
	 * 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.
	 */

However, KASAN helpers are standard C functions following the System V AMD64
ABI, which are allowed to clobber R10. Additionally, if KASAN detects an
issue, kasan_report() is called, which also clobbers R10.

Meanwhile, do_jit() relies on BPF_REG_AX (R10) being preserved across KASAN
checks, such as during atomic fetch operations:

				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 R10 is clobbered during the KASAN check, won't the subsequent atomic or
memory instruction use a corrupted R10 as a memory address or source value,
potentially leading to silent memory corruption or crashes?

>  	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