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

diff --git a/Documentation/ABI/testing/sysfs-driver-ivpu b/Documentation/ABI/testing/sysfs-driver-ivpu
new file mode 100644
index 000000000..91685774e
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-ivpu
@@ -0,0 +1,65 @@
+What:		/sys/bus/pci/drivers/intel_vpu/.../npu_busy_time_us
+Date:		May 2024
+KernelVersion:	6.11
+Contact:	dri-devel@lists.freedesktop.org
+Description:	Time in microseconds that the device spent executing jobs. The time is
+		counted when and only when there are jobs submitted to firmware. This time
+		can be used to measure the utilization of NPU, either by calculating the
+		difference between two timepoints or monitoring utilization percentage by
+		reading periodically. Recommended read period is 1 second to avoid impact
+		on job submission performance. Read-only.
+
+What:		/sys/bus/pci/drivers/intel_vpu/.../npu_memory_utilization
+Date:		Jan 2025
+KernelVersion:	6.15
+Contact:	dri-devel@lists.freedesktop.org
+Description:	Current NPU memory utilization in bytes. Reports the total size of all
+		resident buffer objects allocated for NPU use. Read-only.
+
+What:		/sys/bus/pci/drivers/intel_vpu/.../freq/hw_min_freq
+Date:		April 2026
+KernelVersion:	7.2
+Contact:	dri-devel@lists.freedesktop.org
+Description:	Minimum frequency in MHz supported by the NPU hardware. This is a
+		hardware capability and cannot be changed. Read-only.
+
+What:		/sys/bus/pci/drivers/intel_vpu/.../freq/hw_efficient_freq
+Date:		April 2026
+KernelVersion:	7.2
+Contact:	dri-devel@lists.freedesktop.org
+Description:	Most efficient operating frequency in MHz for the NPU. This represents
+		the frequency at which the NPU operates most efficiently in terms of power
+		and performance. Read-only.
+
+What:		/sys/bus/pci/drivers/intel_vpu/.../freq/hw_max_freq
+Date:		April 2026
+KernelVersion:	7.2
+Contact:	dri-devel@lists.freedesktop.org
+Description:	Maximum frequency in MHz supported by the NPU hardware. This is a
+		hardware capability and cannot be changed. Read-only.
+
+What:		/sys/bus/pci/drivers/intel_vpu/.../freq/current_freq
+Date:		April 2026
+KernelVersion:	7.2
+Contact:	dri-devel@lists.freedesktop.org
+Description:	Current operating frequency in MHz of the NPU. The value is valid only
+		when the device is active; returns 0 when idle. The actual frequency may
+		be lower than the requested range due to power or thermal constraints.
+		Read-only.
+
+What:		/sys/bus/pci/drivers/intel_vpu/.../freq/set_min_freq
+Date:		April 2026
+KernelVersion:	7.2
+Contact:	dri-devel@lists.freedesktop.org
+Description:	Configured minimum operating frequency in MHz (50XX devices and newer).
+		Values written are clamped to hardware limits (hw_min_freq to hw_max_freq).
+		If set_min_freq exceeds set_max_freq, the driver clamps set_min_freq to
+		set_max_freq when selecting the operating frequency. Read-write.
+
+What:		/sys/bus/pci/drivers/intel_vpu/.../freq/set_max_freq
+Date:		April 2026
+KernelVersion:	7.2
+Contact:	dri-devel@lists.freedesktop.org
+Description:	Configured maximum operating frequency in MHz (50XX devices and newer).
+		Values written are clamped to hardware limits (hw_min_freq to hw_max_freq).
+		Read-write.