x86/kprobes: Fix crash when probing CS CALL instructionsgrafted

When using eBPF to probe CS CALL instructions within a function,
a crash can be triggered.

The eBPF tool probes offset 257 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

Which triggers this crash:

  BUG: unable to handle page fault for address: 00000000000f41c9
  #PF: supervisor write access in kernel mode
  #PF: error_code(0x0002) - not-present page
  PGD 0 P4D 0
  Oops: 0002 [#1] SMP NOPTI
  CPU: 1 PID: 0 Comm: swapper/1 Kdump: loaded Tainted: P
  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, a 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.

[ mingo: Refined the changelog ]

Fixes: 6256e668b7af ("x86/kprobes: Use int3 instead of debug trap for single-step")
Suggested-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Signed-off-by: Jinke Han <jinkehan@didiglobal.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Acked-by: Yafang Shao <laoar.shao@gmail.com>
Acked-by: Borislav Petkov <bp@alien8.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: https://patch.msgid.link/20260908073742.GA10517@didi-ThinkCentre-M920t-N000

1 files changed, 100 insertions, 0 deletions

diff --git a/arch/sh/Kconfig.cpu b/arch/sh/Kconfig.cpu
new file mode 100644
index 000000000..336c54369
--- /dev/null
+++ b/arch/sh/Kconfig.cpu
@@ -0,0 +1,100 @@
+# SPDX-License-Identifier: GPL-2.0
+menu "Processor features"
+
+choice
+	prompt "Endianness selection" 
+	default CPU_LITTLE_ENDIAN
+	help
+	  Some SuperH machines can be configured for either little or big
+	  endian byte order. These modes require different kernels.
+
+config CPU_LITTLE_ENDIAN
+	bool "Little Endian"
+
+config CPU_BIG_ENDIAN
+	bool "Big Endian"
+
+endchoice
+
+config SH_FPU
+	def_bool y
+	prompt "FPU support"
+	depends on CPU_HAS_FPU
+	help
+	  Selecting this option will enable support for SH processors that
+	  have FPU units (ie, SH77xx).
+
+	  This option must be set in order to enable the FPU.
+
+config SH_FPU_EMU
+	def_bool n
+	prompt "FPU emulation support"
+	depends on !SH_FPU
+	help
+	  Selecting this option will enable support for software FPU emulation.
+	  Most SH-3 users will want to say Y here, whereas most SH-4 users will
+	  want to say N.
+
+config SH_DSP
+	def_bool y
+	prompt "DSP support"
+	depends on CPU_HAS_DSP
+	help
+	  Selecting this option will enable support for SH processors that
+	  have DSP units (ie, SH2-DSP, SH3-DSP, and SH4AL-DSP).
+
+	  This option must be set in order to enable the DSP.
+
+config SH_ADC
+	def_bool y
+	prompt "ADC support"
+	depends on CPU_SH3
+	help
+	  Selecting this option will allow the Linux kernel to use SH3 on-chip
+	  ADC module.
+
+	  If unsure, say N.
+
+config SH_STORE_QUEUES
+	bool "Support for Store Queues"
+	depends on CPU_SH4
+	help
+	  Selecting this option will enable an in-kernel API for manipulating
+	  the store queues integrated in the SH-4 processors.
+
+config SPECULATIVE_EXECUTION
+	bool "Speculative subroutine return"
+	depends on CPU_SUBTYPE_SH7780 || CPU_SUBTYPE_SH7785 || CPU_SUBTYPE_SH7786
+	help
+	  This enables support for a speculative instruction fetch for
+	  subroutine return. There are various pitfalls associated with
+	  this, as outlined in the SH7780 hardware manual.
+
+	  If unsure, say N.
+
+config CPU_HAS_INTEVT
+	bool
+
+config CPU_HAS_IPR_IRQ
+	bool
+
+config CPU_HAS_SR_RB
+	bool
+	help
+	  This will enable the use of SR.RB register bank usage. Processors
+	  that are lacking this bit must have another method in place for
+	  accomplishing what is taken care of by the banked registers.
+
+	  See <file:Documentation/arch/sh/register-banks.rst> for further
+	  information on SR.RB and register banking in the kernel in general.
+
+config CPU_HAS_PTEAEX
+	bool
+
+config CPU_HAS_DSP
+	bool
+
+config CPU_HAS_FPU
+	bool
+
+endmenu