Re: [PATCH v2] x86/kprobe: Fix crash when probe cs call

[Google]

On Tue, 8 Sep 2026 03:24:16 +0800
Jinke Han <jinkehan@xxxxxxxxxxxxxx> wrote:

> When I used eBPF to probe the call instructions within a function,
> we encountered a kernel crash.
> 
> The ebpf tool probes the 257 offset of the __hrtimer_run_queues
> function.
> 
> <__hrtimer_run_queues+249>:  nopl   0x0(%rax,%rax,1)
> <__hrtimer_run_queues+254>:  mov    %r14,%rdi
> <__hrtimer_run_queues+257>:  cs call <__x86_indirect_thunk_r12>
> <__hrtimer_run_queues+263>:  mov    %eax,%r12d
> <__hrtimer_run_queues+266>:  xchg   %ax,%ax
> <__hrtimer_run_queues+268>:  mov    %r13,%rdi
> 
> The scene of kernel crash is as follows:
> 
> [73665.737181] BUG: unable to handle page fault for address: 00000000000f41c9
> [73665.744253] #PF: supervisor write access in kernel mode
> [73665.749643] #PF: error_code(0x0002) - not-present page
> [73665.754843] PGD 0 P4D 0
> [73665.757390] Oops: 0002 [#1] SMP NOPTI
> [73665.761073] CPU: 1 PID: 0 Comm: swapper/1 Kdump: loaded Tainted: P
> [73665.782671] RIP: 0010:__hrtimer_run_queues+0x106/0x230
> 
> Note that __hrtimer_run_queues+0x106 is __hrtimer_run_queues+262, which is
> at the 6th byte of the above cs call instruction. Since the cs call
> instruction occupies 6 bytes, the exception occurred in the middle of that
> call instruction.
> 
> The root cause is that when using eBPF tools to probe in the middle of a
> function, kprobe with int3 is used as the underlying implementation.
> During single-step emulation of the original call instruction,
> int3_emulate_call assumes that the probed call instruction is 5 bytes
> long. However, the actual CS-prefixed call instruction occupies 6 bytes,
> so it constructs an incorrect exception return address. When the CPU
> returns from the kprobe handler, the next instruction to be executed is at
> the address of the last byte of that CS call instruction. Coincidentally,
> starting from that address, the CPU fetches and decodes a completely
> different instruction, which ultimately triggers a kernel crash.
> 
> Fix the issue by using the actual instruction length obtained from
> the instruction decoder when constructing the exception return
> address, rather than relying on the hardcoded CALL_INSN_SIZE macro.
> 
> Cc: stable@xxxxxxxxxx
> Cc: linux-trace-kernel@xxxxxxxxxxxxxxx
> Fixes: 6256e668b7af ("x86/kprobes: Use int3 instead of debug trap for single-step")
> Suggested-by: Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx>
> Acked-by: Yafang Shao <laoar.shao@xxxxxxxxx>
> Signed-off-by: Jinke Han <jinkehan@xxxxxxxxxxxxxx>

Thanks for fixing! I have just one comment here;

[...]
 
> @@ -2180,8 +2181,14 @@ int3_exception_notify(struct notifier_block *self, unsigned long val, void *data
>  
>  	if (regs->ip - INT3_INSN_SIZE != selftest)
>  		return NOTIFY_DONE;
> -
> -	int3_emulate_call(regs, (unsigned long)&int3_selftest_callee);
> +	/*
> +	 * As seen in int3_selftest_asm, the effective return address
> +	 * should be placed immediately after the instruction sequence
> +	 * [int3; nop; nop; nop; nop.]. Therefore, CALL_INSN_SIZE works
> +	 * perfectly well here.

Nit: This explanation is somewhat wrong. alternatives only support 5-byte
call. The TEXT_POKE_MAX_OPCODE_SIZE is 5. When len == 6, alternative.c
explicitly reserves this only for 0x0f prefixed Jcc.d32

See alternative.c 
> /*
>  * NOTE: crazy scheme to allow patching Jcc.d32 but not increase the size of
>  * this thing. When len == 6 everything is prefixed with 0x0f and we map
>  * opcode to Jcc.d8, using len to distinguish.
>  */

So we don't need to take care of 6 bytes call here.

Others looks good to me.

Reviewed-by: Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx>

BTW, can this be picked via tip tree ? or I can pick it.

Thank you,

-- 
Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx>