Re: [PATCH bpf-next v7 4/9] bpf, x86: emit KASAN checks in x86 JITed programs

["Kumar Kartikeya Dwivedi" <memxor@gmail.com>]

On Tue Aug 25, 2026 at 2:12 AM CEST, Ihor Solodrai wrote:
> On 8/23/26 3:30 PM, Kumar Kartikeya Dwivedi wrote:
>> On Sat Aug 22, 2026 at 1:33 AM CEST, sashiko-bot wrote:
>>> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
>>> - [High] `emit_kasan_check` fails to save the caller-saved register %r10 (BPF_REG_AX), which corrupts BPF_REG_0 and memory pointers during atomic fetch operations.
>>> --
>>>
>>> --- Patch [4]: [PATCH bpf-next v7 4/9] bpf, x86: emit KASAN checks in x86 JITed programs ---
>>> commit 6bca50db6e9af9416363fe2e60f4e42f924950c9
>>> Author: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>
>>>
>>> bpf, x86: emit KASAN checks in x86 JITed programs
>>>
>>> Insert KASAN shadow memory checks before memory load and store
>>> operations in JIT-compiled BPF programs. This helps detect memory safety
>>> bugs such as use-after-free and out-of-bounds accesses at runtime.
>>>
>>>> diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
>>>> index 13ba3232993ac..8134d028a2f2c 100644
>>>> --- a/arch/x86/net/bpf_jit_comp.c
>>>> +++ b/arch/x86/net/bpf_jit_comp.c
>>>
>>> [ ... ]
>>>
>>>> @@ -1110,6 +1121,92 @@ static void maybe_emit_1mod(u8 **pprog, u32 reg, bool is64)
>>>>  	*pprog = prog;
>>>>  }
>>>>
>>>> +static int emit_kasan_check(struct bpf_verifier_env *env, u8 **pprog,
>>>> +			    u32 addr_reg, struct bpf_insn *insn, u8 *ip,
>>>> +			    bool is_write)
>>>> +{
>>>> +#ifdef CONFIG_BPF_JIT_KASAN
>>>> +	u32 bpf_size = BPF_SIZE(insn->code);
>>>> +	s32 off = insn->off;
>>>> +	u8 *prog = *pprog;
>>>> +	void *kasan_func;
>>>> +
>>>> +	if (!env)
>>>> +		return 0;
>>>> +
>>>> +	/* Derive KASAN check function from access type and size */
>>>> +	switch (bpf_size) {
>>>> +	case BPF_B:
>>>> +		kasan_func = is_write ? __asan_store1 : __asan_load1;
>>>> +		break;
>>>> +	case BPF_H:
>>>> +		kasan_func = is_write ? __asan_store2 : __asan_load2;
>>>> +		break;
>>>> +	case BPF_W:
>>>> +		kasan_func = is_write ? __asan_store4 : __asan_load4;
>>>> +		break;
>>>> +	case BPF_DW:
>>>> +		kasan_func = is_write ? __asan_store8 : __asan_load8;
>>>> +		break;
>>>> +	default:
>>>> +		return -EINVAL;
>>>> +	}
>>>> +
>>>> +	/* Save rax */
>>>> +	EMIT1(0x50);
>>>> +	/* Save rcx */
>>>> +	EMIT1(0x51);
>>>> +	/* Save rdx */
>>>> +	EMIT1(0x52);
>>>> +	/* Save rsi */
>>>> +	EMIT1(0x56);
>>>> +	/* Save rdi */
>>>> +	EMIT1(0x57);
>>>> +	/* Save r8 */
>>>> +	EMIT2(0x41, 0x50);
>>>> +	/* Save r9 */
>>>> +	EMIT2(0x41, 0x51);
>>>> +	/*
>>>> +	 * 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.
>>>> +	 */
>>>> +
>>>> +	/* mov rdi, addr_reg */
>>>
>>> [Severity: High]
>>> Is it safe to skip saving %r10 and %r11 here?
>>>
>>> In the x86 BPF JIT, %r10 is mapped to BPF_REG_AX. During atomic fetch
>>> operations, BPF_REG_0 is stashed into BPF_REG_AX before calling
>>> emit_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 (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)) {
>>>         if (!accesses_stack_only) {
>>>             err = emit_kasan_check(env, &prog, real_dst_reg, insn, ip, true);
>>>     ...
>>> }
>>>
>>> Since the KASAN helpers are standard C functions, they are permitted by the
>>> System V AMD64 ABI to clobber caller-saved registers like %r10 (especially if
>>> kasan_report is called).
>>>
>>> If %r10 is clobbered, could this corrupt the stashed BPF_REG_0 and potentially
>>> cause a crash when real_dst_reg is used as a memory pointer in the subsequent
>>> emit_ldx() call?
>>>
>>> arch/x86/net/bpf_jit_comp.c:do_jit() {
>>>     ...
>>>     /* Load old value */
>>>     emit_ldx(&prog, BPF_SIZE(insn->code), BPF_REG_0, real_dst_reg, insn->off);
>>>     ...
>>>     /* Restore R0 after clobbering RAX */
>>>     emit_mov_reg(&prog, true, BPF_REG_0, BPF_REG_AX);
>>>     ...
>>> }
>>
>> This looks like a real bug, R10 is used for both atomics and constant blinding.
>> We probably also should save R11.
>
>
> Hi Kumar, Alexis.
>
> This topic has a bit of history now [1][2].

From [1],

"I built the kernel with gcc 11.5, gcc 15.2 and clang 22 and
disassembled __asan_{load,store}{1,2,4,8}: none of them touch r10 or
r11. gcc goes up to r8, clang uses nothing above rdi."

Isn't this dependent on register pressure inside the function, i.e. depending on
different code or whatever, it might begin using those registers?

> I don't quite like it, but IMO we should give in to the bots.
>
> Reasons to save r10 and r11:
> * SystemV ABI
> * bots wouldn't shut up about it (think of future llm bot reports!)
> * if our analysis of the kasan helpers is wrong about r10/r11 usage OR
>   if something changes (the helpers themselves, the compilers, build
>   flags, JIT's usage of r10/r11 etc.) - we'll get clobbered regs
>
> Reasons to *not* save r10 and r11:
> * we make the bpf prog a bit smaller and faster, the win is not very
>   clear but it's percentages, not a factor
>

Yeah, also, we're already saving a ton of other registers, I don't know whether
saving two would matter, even if it wasn't incorrect. I wouldn't worry too much
about KASAN performance, it's already orders of magnitude slower than normal
kernel build.

> A counter-argument to clobbering is that a kasan bug here most likely
> means a bug in the verifier, so it doesn't matter if machine dies.
>
> A counter-argument to that would be: why deliberately increase the bug
> surface and let the machine die if we can easily prevent it?
>
> Pasting below a clobbering reproducer from my clanker.
>
> [1] https://lore.kernel.org/all/5f38c9a5-a8a3-4bed-bb8c-b7260a1c1a11@linux.dev/
> [2] https://lore.kernel.org/all/CAADnVQ+c9h_wuNwj8pjx885oNErGY7bxxCwKi+DiJ0XKSpyYfg@mail.gmail.com/
>
> [...]