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

diff --git a/drivers/parisc/Kconfig b/drivers/parisc/Kconfig
new file mode 100644
index 000000000..9cbcf1552
--- /dev/null
+++ b/drivers/parisc/Kconfig
@@ -0,0 +1,161 @@
+# SPDX-License-Identifier: GPL-2.0-only
+menu "Bus options (PCI, PCMCIA, EISA, GSC, ISA)"
+
+config GSC
+	bool "VSC/GSC/HSC bus support"
+	select HAVE_EISA
+	select HAS_IOPORT
+	default y
+	help
+	  The VSC, GSC and HSC busses were used from the earliest 700-series
+	  workstations up to and including the C360/J2240 workstations.  They
+	  were also used in servers from the E-class to the K-class.  They
+	  are not found in B1000, C3000, J5000, A500, L1000, N4000 and upwards.
+	  If in doubt, say "Y".
+
+config HPPB
+	bool "HP-PB bus support"
+	depends on GSC
+	help
+	  The HP-PB bus was used in the Nova class and K-class servers.
+	  If in doubt, say "Y"
+
+config IOMMU_CCIO
+	bool "U2/Uturn I/O MMU"
+	depends on GSC
+	help
+	  Say Y here to enable DMA management routines for the first
+	  generation of PA-RISC cache-coherent machines.  Programs the
+	  U2/Uturn chip in "Virtual Mode" and use the I/O MMU.
+
+config GSC_LASI
+	bool "Lasi I/O support"
+	depends on GSC
+	help
+	  Say Y here to support the Lasi multifunction chip found in
+	  many PA-RISC workstations & servers.	It includes interfaces
+	  for a parallel port, serial port, NCR 53c710 SCSI, Apricot
+	  Ethernet, Harmony audio, PS/2 keyboard & mouse, ISDN, telephony
+	  and floppy.  Note that you must still enable all the individual
+	  drivers for these chips.
+
+config GSC_WAX
+	bool "Wax I/O support"
+	depends on GSC
+	help
+	  Say Y here to support the Wax multifunction chip found in some
+	  older systems, including B/C/D/R class and 715/64, 715/80 and
+	  715/100.  Wax includes an EISA adapter, a serial port (not always
+	  used), a HIL interface chip and is also known to be used as the
+	  GSC bridge for an X.25 GSC card.
+
+config ISA
+	bool "ISA support"
+	depends on EISA
+	help
+	  If you want to plug an ISA card into your EISA bus, say Y here.
+	  Most people should say N.
+
+config GSC_DINO
+	bool "GSCtoPCI/Dino PCI support"
+	depends on PCI && GSC
+	help
+	  Say Y here to support the Dino & Cujo GSC to PCI bridges found in
+	  machines from the B132 to the C360, the J2240 and the A180.  Some
+	  GSC/HSC cards (eg gigabit & dual 100 Mbit Ethernet) have a Dino on
+	  the card, and you also need to say Y here if you have such a card.
+	  Note that Dino also supplies one of the serial ports on certain
+	  machines.  If in doubt, say Y.
+
+config PCI_LBA
+	bool "LBA/Elroy PCI support"
+	depends on PCI
+	help
+	  Say Y here to support the Elroy PCI Lower Bus Adapter.  This is
+	  present on B, C, J, L and N-class machines with 4-digit model
+	  numbers and the A400/A500.
+
+config IOSAPIC
+	bool
+	depends on PCI_LBA
+	default PCI_LBA
+
+config IOMMU_SBA
+	bool
+	depends on PCI_LBA
+	default PCI_LBA
+
+endmenu
+
+menu "PA-RISC specific drivers"
+
+config SUPERIO
+	bool "SuperIO (SuckyIO) support"
+	depends on PCI_LBA
+	default y
+	help
+	  Say Y here to support the SuperIO chip found in Bxxxx, C3xxx and
+	  J5xxx+ machines. This enables IDE, Floppy, Parallel Port, and
+	  Serial port on those machines.
+
+config CHASSIS_LCD_LED
+	bool "Chassis LCD and LED support"
+	depends on LEDS_CLASS=y
+	default y
+	select LEDS_TRIGGERS
+	help
+	  Say Y here if you want to enable support for the Heartbeat,
+	  Disk/Network activities LEDs on some PA-RISC machines,
+	  or support for the LCD that can be found on recent material.
+	
+	  This has nothing to do with LED State support for A and E class.
+	
+	  If unsure, say Y.
+
+config PDC_CHASSIS
+	bool "PDC chassis state codes support"
+	default y
+	help
+	  Say Y here if you want to enable support for Chassis codes.
+	  That includes support for LED State front panel as found on E
+	  class, and support for the GSP Virtual Front Panel (LED State and
+	  message logging)  as found on high end servers such as A, L and
+	  N-class.
+	  This driver will also display progress messages on LCD display,
+	  such as "INI", "RUN" and "FLT", and might thus clobber messages
+	  shown by the LED/LCD driver.
+	  This driver updates the state panel (LED and/or LCD) upon system
+	  state change (eg: boot, shutdown or panic).
+	  
+	  If unsure, say Y.
+
+
+config PDC_CHASSIS_WARN
+	bool "PDC chassis warnings support"
+	depends on PROC_FS
+	default y
+	help
+	  Say Y here if you want to enable support for Chassis warnings.
+	  This will add a proc entry '/proc/chassis' giving some information
+	  about the overall health state of the system.
+	  This includes NVRAM battery level, overtemp or failures such as
+	  fans or power units.
+
+	  If unsure, say Y.
+
+
+config PDC_STABLE
+	tristate "PDC Stable Storage support"
+	depends on SYSFS
+	default y
+	help
+	  Say Y here if you want to enable support for accessing Stable Storage
+	  variables (PDC non volatile variables such as Primary Boot Path,
+	  Console Path, Autoboot, Autosearch, etc) through SysFS.
+	
+	  If unsure, say Y.
+	
+	  To compile this driver as a module, choose M here.
+	  The module will be called pdc_stable.
+
+endmenu