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, 165 insertions, 0 deletions

diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig
new file mode 100644
index 000000000..c232054fd
--- /dev/null
+++ b/drivers/i2c/Kconfig
@@ -0,0 +1,165 @@
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# I2C subsystem configuration
+#
+
+menu "I2C support"
+
+config I2C
+	tristate "I2C support"
+	select RT_MUTEXES
+	select IRQ_DOMAIN
+	help
+	  I2C (pronounce: I-squared-C) is a slow serial bus protocol used in
+	  many micro controller applications and developed by Philips.  SMBus,
+	  or System Management Bus is a subset of the I2C protocol.  More
+	  information is contained in the directory <file:Documentation/i2c/>,
+	  especially in the file called "summary" there.
+
+	  Both I2C and SMBus are supported here. You will need this for
+	  hardware sensors support, and also for Video For Linux support.
+
+	  If you want I2C support, you should say Y here and also to the
+	  specific driver for your bus adapter(s) below.
+
+	  This I2C support can also be built as a module.  If so, the module
+	  will be called i2c-core.
+
+config ACPI_I2C_OPREGION
+	bool "ACPI I2C Operation region support"
+	depends on I2C=y && ACPI
+	default y
+	help
+	  Say Y here if you want to enable ACPI I2C operation region support.
+	  Operation Regions allow firmware (BIOS) code to access I2C slave devices,
+	  such as smart batteries through an I2C host controller driver.
+
+if I2C
+
+config I2C_BOARDINFO
+	bool
+	default y
+
+config I2C_CHARDEV
+	tristate "I2C device interface"
+	help
+	  Say Y here to use i2c-* device files, usually found in the /dev
+	  directory on your system.  They make it possible to have user-space
+	  programs use the I2C bus.  Information on how to do this is
+	  contained in the file <file:Documentation/i2c/dev-interface.rst>.
+
+	  This support is also available as a module.  If so, the module 
+	  will be called i2c-dev.
+
+config I2C_MUX
+	tristate "I2C bus multiplexing support"
+	help
+	  Say Y here if you want the I2C core to support the ability to
+	  handle multiplexed I2C bus topologies, by presenting each
+	  multiplexed segment as a I2C adapter.
+
+	  This support is also available as a module.  If so, the module
+	  will be called i2c-mux.
+
+source "drivers/i2c/muxes/Kconfig"
+
+config I2C_ATR
+	tristate "I2C Address Translator (ATR) support" if COMPILE_TEST
+	help
+	  Enable support for I2C Address Translator (ATR) chips.
+
+	  An ATR allows accessing multiple I2C busses from a single
+	  physical bus via address translation instead of bus selection as
+	  i2c-muxes do.
+
+config I2C_HELPER_AUTO
+	bool "Autoselect pertinent helper modules"
+	default y
+	help
+	  Some I2C bus drivers require so-called "I2C algorithm" modules
+	  to work. These are basically software-only abstractions of generic
+	  I2C interfaces. This option will autoselect them so that you don't
+	  have to care.
+
+	  Unselect this only if you need to enable additional helper
+	  modules, for example for use with external I2C bus drivers.
+
+	  In doubt, say Y.
+
+config I2C_SMBUS
+	tristate "SMBus-specific protocols" if !I2C_HELPER_AUTO
+	help
+	  Say Y here if you want support for SMBus extensions to the I2C
+	  specification. At the moment, two extensions are supported:
+	  the SMBus Alert protocol and the SMBus Host Notify protocol.
+
+	  This support is also available as a module.  If so, the module
+	  will be called i2c-smbus.
+
+source "drivers/i2c/algos/Kconfig"
+source "drivers/i2c/busses/Kconfig"
+
+config I2C_STUB
+	tristate "I2C/SMBus Test Stub"
+	depends on m
+	help
+	  This module may be useful to developers of SMBus client drivers,
+	  especially for certain kinds of sensor chips.
+
+	  If you do build this module, be sure to read the notes and warnings
+	  in <file:Documentation/i2c/i2c-stub.rst>.
+
+	  If you don't know what to do here, definitely say N.
+
+config I2C_SLAVE
+	bool "I2C slave support"
+	help
+	  This enables Linux to act as an I2C slave device. Note that your I2C
+	  bus master driver also needs to support this functionality. Please
+	  read Documentation/i2c/slave-interface.rst for further details.
+
+if I2C_SLAVE
+
+config I2C_SLAVE_EEPROM
+	tristate "I2C eeprom slave driver"
+	help
+	  This backend makes Linux behave like an I2C EEPROM. Please read
+	  Documentation/i2c/slave-eeprom-backend.rst for further details.
+
+config I2C_SLAVE_TESTUNIT
+	tristate "I2C testunit driver"
+	help
+	  This backend can be used to trigger test cases for I2C bus masters
+	  which require a remote device with certain capabilities, e.g.
+	  multi-master, SMBus Host Notify, etc. Please read
+	  Documentation/i2c/slave-testunit-backend.rst for further details.
+
+endif
+
+config I2C_DEBUG_CORE
+	bool "I2C Core debugging messages"
+	help
+	  Say Y here if you want the I2C core to produce a bunch of debug
+	  messages to the system log.  Select this if you are having a
+	  problem with I2C support and want to see more of what is going on.
+
+config I2C_DEBUG_ALGO
+	bool "I2C Algorithm debugging messages"
+	help
+	  Say Y here if you want the I2C algorithm drivers to produce a bunch
+	  of debug messages to the system log.  Select this if you are having
+	  a problem with I2C support and want to see more of what is going
+	  on.
+
+config I2C_DEBUG_BUS
+	bool "I2C Bus debugging messages"
+	depends on HAS_IOMEM
+	help
+	  Say Y here if you want the I2C bus drivers to produce a bunch of
+	  debug messages to the system log.  Select this if you are having
+	  a problem with I2C support and want to see more of what is going
+	  on.
+
+endif # I2C
+
+endmenu