]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
6.1-stable patches
authorGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Mon, 8 Jan 2024 12:40:36 +0000 (13:40 +0100)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Mon, 8 Jan 2024 12:40:36 +0000 (13:40 +0100)
added patches:
firewire-ohci-suppress-unexpected-system-reboot-in-amd-ryzen-machines-and-asm108x-vt630x-pcie-cards.patch
i2c-core-fix-atomic-xfer-check-for-non-preempt-config.patch
mm-fix-unmap_mapping_range-high-bits-shift-bug.patch
x86-kprobes-fix-incorrect-return-address-calculation-in-kprobe_emulate_call_indirect.patch

queue-6.1/firewire-ohci-suppress-unexpected-system-reboot-in-amd-ryzen-machines-and-asm108x-vt630x-pcie-cards.patch [new file with mode: 0644]
queue-6.1/i2c-core-fix-atomic-xfer-check-for-non-preempt-config.patch [new file with mode: 0644]
queue-6.1/mm-fix-unmap_mapping_range-high-bits-shift-bug.patch [new file with mode: 0644]
queue-6.1/series
queue-6.1/x86-kprobes-fix-incorrect-return-address-calculation-in-kprobe_emulate_call_indirect.patch [new file with mode: 0644]

diff --git a/queue-6.1/firewire-ohci-suppress-unexpected-system-reboot-in-amd-ryzen-machines-and-asm108x-vt630x-pcie-cards.patch b/queue-6.1/firewire-ohci-suppress-unexpected-system-reboot-in-amd-ryzen-machines-and-asm108x-vt630x-pcie-cards.patch
new file mode 100644 (file)
index 0000000..d6ca812
--- /dev/null
@@ -0,0 +1,125 @@
+From ac9184fbb8478dab4a0724b279f94956b69be827 Mon Sep 17 00:00:00 2001
+From: Takashi Sakamoto <o-takashi@sakamocchi.jp>
+Date: Tue, 2 Jan 2024 20:01:50 +0900
+Subject: firewire: ohci: suppress unexpected system reboot in AMD Ryzen machines and ASM108x/VT630x PCIe cards
+
+From: Takashi Sakamoto <o-takashi@sakamocchi.jp>
+
+commit ac9184fbb8478dab4a0724b279f94956b69be827 upstream.
+
+VIA VT6306/6307/6308 provides PCI interface compliant to 1394 OHCI. When
+the hardware is combined with Asmedia ASM1083/1085 PCIe-to-PCI bus bridge,
+it appears that accesses to its 'Isochronous Cycle Timer' register (offset
+0xf0 on PCI memory space) often causes unexpected system reboot in any
+type of AMD Ryzen machine (both 0x17 and 0x19 families). It does not
+appears in the other type of machine (AMD pre-Ryzen machine, Intel
+machine, at least), or in the other OHCI 1394 hardware (e.g. Texas
+Instruments).
+
+The issue explicitly appears at a commit dcadfd7f7c74 ("firewire: core:
+use union for callback of transaction completion") added to v6.5 kernel.
+It changed 1394 OHCI driver to access to the register every time to
+dispatch local asynchronous transaction. However, the issue exists in
+older version of kernel as long as it runs in AMD Ryzen machine, since
+the access to the register is required to maintain bus time. It is not
+hard to imagine that users experience the unexpected system reboot when
+generating bus reset by plugging any devices in, or reading the register
+by time-aware application programs; e.g. audio sample processing.
+
+This commit suppresses the unexpected system reboot in the combination of
+hardware. It avoids the access itself. As a result, the software stack can
+not provide the hardware time anymore to unit drivers, userspace
+applications, and nodes in the same IEEE 1394 bus. It brings apparent
+disadvantage since time-aware application programs require it, while
+time-unaware applications are available again; e.g. sbp2.
+
+Cc: stable@vger.kernel.org
+Reported-by: Jiri Slaby <jirislaby@kernel.org>
+Closes: https://bugzilla.suse.com/show_bug.cgi?id=1215436
+Reported-by: Mario Limonciello <mario.limonciello@amd.com>
+Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217994
+Reported-by: Tobias Gruetzmacher <tobias-lists@23.gs>
+Closes: https://sourceforge.net/p/linux1394/mailman/message/58711901/
+Closes: https://bugzilla.redhat.com/show_bug.cgi?id=2240973
+Closes: https://bugs.launchpad.net/linux/+bug/2043905
+Link: https://lore.kernel.org/r/20240102110150.244475-1-o-takashi@sakamocchi.jp
+Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/firewire/ohci.c |   51 ++++++++++++++++++++++++++++++++++++++++++++++++
+ 1 file changed, 51 insertions(+)
+
+--- a/drivers/firewire/ohci.c
++++ b/drivers/firewire/ohci.c
+@@ -279,6 +279,51 @@ static char ohci_driver_name[] = KBUILD_
+ #define QUIRK_TI_SLLZ059              0x20
+ #define QUIRK_IR_WAKE                 0x40
++// On PCI Express Root Complex in any type of AMD Ryzen machine, VIA VT6306/6307/6308 with Asmedia
++// ASM1083/1085 brings an inconvenience that the read accesses to 'Isochronous Cycle Timer' register
++// (at offset 0xf0 in PCI I/O space) often causes unexpected system reboot. The mechanism is not
++// clear, since the read access to the other registers is enough safe; e.g. 'Node ID' register,
++// while it is probable due to detection of any type of PCIe error.
++#define QUIRK_REBOOT_BY_CYCLE_TIMER_READ      0x80000000
++
++#if IS_ENABLED(CONFIG_X86)
++
++static bool has_reboot_by_cycle_timer_read_quirk(const struct fw_ohci *ohci)
++{
++      return !!(ohci->quirks & QUIRK_REBOOT_BY_CYCLE_TIMER_READ);
++}
++
++#define PCI_DEVICE_ID_ASMEDIA_ASM108X 0x1080
++
++static bool detect_vt630x_with_asm1083_on_amd_ryzen_machine(const struct pci_dev *pdev)
++{
++      const struct pci_dev *pcie_to_pci_bridge;
++
++      // Detect any type of AMD Ryzen machine.
++      if (!static_cpu_has(X86_FEATURE_ZEN))
++              return false;
++
++      // Detect VIA VT6306/6307/6308.
++      if (pdev->vendor != PCI_VENDOR_ID_VIA)
++              return false;
++      if (pdev->device != PCI_DEVICE_ID_VIA_VT630X)
++              return false;
++
++      // Detect Asmedia ASM1083/1085.
++      pcie_to_pci_bridge = pdev->bus->self;
++      if (pcie_to_pci_bridge->vendor != PCI_VENDOR_ID_ASMEDIA)
++              return false;
++      if (pcie_to_pci_bridge->device != PCI_DEVICE_ID_ASMEDIA_ASM108X)
++              return false;
++
++      return true;
++}
++
++#else
++#define has_reboot_by_cycle_timer_read_quirk(ohci) false
++#define detect_vt630x_with_asm1083_on_amd_ryzen_machine(pdev) false
++#endif
++
+ /* In case of multiple matches in ohci_quirks[], only the first one is used. */
+ static const struct {
+       unsigned short vendor, device, revision, flags;
+@@ -1713,6 +1758,9 @@ static u32 get_cycle_time(struct fw_ohci
+       s32 diff01, diff12;
+       int i;
++      if (has_reboot_by_cycle_timer_read_quirk(ohci))
++              return 0;
++
+       c2 = reg_read(ohci, OHCI1394_IsochronousCycleTimer);
+       if (ohci->quirks & QUIRK_CYCLE_TIMER) {
+@@ -3615,6 +3663,9 @@ static int pci_probe(struct pci_dev *dev
+       if (param_quirks)
+               ohci->quirks = param_quirks;
++      if (detect_vt630x_with_asm1083_on_amd_ryzen_machine(dev))
++              ohci->quirks |= QUIRK_REBOOT_BY_CYCLE_TIMER_READ;
++
+       /*
+        * Because dma_alloc_coherent() allocates at least one page,
+        * we save space by using a common buffer for the AR request/
diff --git a/queue-6.1/i2c-core-fix-atomic-xfer-check-for-non-preempt-config.patch b/queue-6.1/i2c-core-fix-atomic-xfer-check-for-non-preempt-config.patch
new file mode 100644 (file)
index 0000000..89d09b9
--- /dev/null
@@ -0,0 +1,59 @@
+From a3368e1186e3ce8e38f78cbca019622095b1f331 Mon Sep 17 00:00:00 2001
+From: Benjamin Bara <benjamin.bara@skidata.com>
+Date: Thu, 4 Jan 2024 09:17:08 +0100
+Subject: i2c: core: Fix atomic xfer check for non-preempt config
+
+From: Benjamin Bara <benjamin.bara@skidata.com>
+
+commit a3368e1186e3ce8e38f78cbca019622095b1f331 upstream.
+
+Since commit aa49c90894d0 ("i2c: core: Run atomic i2c xfer when
+!preemptible"), the whole reboot/power off sequence on non-preempt kernels
+is using atomic i2c xfer, as !preemptible() always results to 1.
+
+During device_shutdown(), the i2c might be used a lot and not all busses
+have implemented an atomic xfer handler. This results in a lot of
+avoidable noise, like:
+
+[   12.687169] No atomic I2C transfer handler for 'i2c-0'
+[   12.692313] WARNING: CPU: 6 PID: 275 at drivers/i2c/i2c-core.h:40 i2c_smbus_xfer+0x100/0x118
+...
+
+Fix this by allowing non-atomic xfer when the interrupts are enabled, as
+it was before.
+
+Link: https://lore.kernel.org/r/20231222230106.73f030a5@yea
+Link: https://lore.kernel.org/r/20240102150350.3180741-1-mwalle@kernel.org
+Link: https://lore.kernel.org/linux-i2c/13271b9b-4132-46ef-abf8-2c311967bb46@mailbox.org/
+Fixes: aa49c90894d0 ("i2c: core: Run atomic i2c xfer when !preemptible")
+Cc: stable@vger.kernel.org # v5.2+
+Signed-off-by: Benjamin Bara <benjamin.bara@skidata.com>
+Tested-by: Michael Walle <mwalle@kernel.org>
+Tested-by: Tor Vic <torvic9@mailbox.org>
+[wsa: removed a comment which needs more work, code is ok]
+Signed-off-by: Wolfram Sang <wsa@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/i2c/i2c-core.h |    4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/i2c/i2c-core.h
++++ b/drivers/i2c/i2c-core.h
+@@ -3,6 +3,7 @@
+  * i2c-core.h - interfaces internal to the I2C framework
+  */
++#include <linux/kconfig.h>
+ #include <linux/rwsem.h>
+ struct i2c_devinfo {
+@@ -29,7 +30,8 @@ int i2c_dev_irq_from_resources(const str
+  */
+ static inline bool i2c_in_atomic_xfer_mode(void)
+ {
+-      return system_state > SYSTEM_RUNNING && !preemptible();
++      return system_state > SYSTEM_RUNNING &&
++             (IS_ENABLED(CONFIG_PREEMPT_COUNT) ? !preemptible() : irqs_disabled());
+ }
+ static inline int __i2c_lock_bus_helper(struct i2c_adapter *adap)
diff --git a/queue-6.1/mm-fix-unmap_mapping_range-high-bits-shift-bug.patch b/queue-6.1/mm-fix-unmap_mapping_range-high-bits-shift-bug.patch
new file mode 100644 (file)
index 0000000..18b4088
--- /dev/null
@@ -0,0 +1,81 @@
+From 9eab0421fa94a3dde0d1f7e36ab3294fc306c99d Mon Sep 17 00:00:00 2001
+From: Jiajun Xie <jiajun.xie.sh@gmail.com>
+Date: Wed, 20 Dec 2023 13:28:39 +0800
+Subject: mm: fix unmap_mapping_range high bits shift bug
+
+From: Jiajun Xie <jiajun.xie.sh@gmail.com>
+
+commit 9eab0421fa94a3dde0d1f7e36ab3294fc306c99d upstream.
+
+The bug happens when highest bit of holebegin is 1, suppose holebegin is
+0x8000000111111000, after shift, hba would be 0xfff8000000111111, then
+vma_interval_tree_foreach would look it up fail or leads to the wrong
+result.
+
+error call seq e.g.:
+- mmap(..., offset=0x8000000111111000)
+  |- syscall(mmap, ... unsigned long, off):
+     |- ksys_mmap_pgoff( ... , off >> PAGE_SHIFT);
+
+  here pgoff is correctly shifted to 0x8000000111111,
+  but pass 0x8000000111111000 as holebegin to unmap
+  would then cause terrible result, as shown below:
+
+- unmap_mapping_range(..., loff_t const holebegin)
+  |- pgoff_t hba = holebegin >> PAGE_SHIFT;
+          /* hba = 0xfff8000000111111 unexpectedly */
+
+The issue happens in Heterogeneous computing, where the device(e.g.
+gpu) and host share the same virtual address space.
+
+A simple workflow pattern which hit the issue is:
+        /* host */
+    1. userspace first mmap a file backed VA range with specified offset.
+                        e.g. (offset=0x800..., mmap return: va_a)
+    2. write some data to the corresponding sys page
+                         e.g. (va_a = 0xAABB)
+        /* device */
+    3. gpu workload touches VA, triggers gpu fault and notify the host.
+        /* host */
+    4. reviced gpu fault notification, then it will:
+            4.1 unmap host pages and also takes care of cpu tlb
+                  (use unmap_mapping_range with offset=0x800...)
+            4.2 migrate sys page to device
+            4.3 setup device page table and resolve device fault.
+        /* device */
+    5. gpu workload continued, it accessed va_a and got 0xAABB.
+    6. gpu workload continued, it wrote 0xBBCC to va_a.
+        /* host */
+    7. userspace access va_a, as expected, it will:
+            7.1 trigger cpu vm fault.
+            7.2 driver handling fault to migrate gpu local page to host.
+    8. userspace then could correctly get 0xBBCC from va_a
+    9. done
+
+But in step 4.1, if we hit the bug this patch mentioned, then userspace
+would never trigger cpu fault, and still get the old value: 0xAABB.
+
+Making holebegin unsigned first fixes the bug.
+
+Link: https://lkml.kernel.org/r/20231220052839.26970-1-jiajun.xie.sh@gmail.com
+Signed-off-by: Jiajun Xie <jiajun.xie.sh@gmail.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/memory.c |    4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/mm/memory.c
++++ b/mm/memory.c
+@@ -3617,8 +3617,8 @@ EXPORT_SYMBOL_GPL(unmap_mapping_pages);
+ void unmap_mapping_range(struct address_space *mapping,
+               loff_t const holebegin, loff_t const holelen, int even_cows)
+ {
+-      pgoff_t hba = holebegin >> PAGE_SHIFT;
+-      pgoff_t hlen = (holelen + PAGE_SIZE - 1) >> PAGE_SHIFT;
++      pgoff_t hba = (pgoff_t)(holebegin) >> PAGE_SHIFT;
++      pgoff_t hlen = ((pgoff_t)(holelen) + PAGE_SIZE - 1) >> PAGE_SHIFT;
+       /* Check for overflow. */
+       if (sizeof(holelen) > sizeof(hlen)) {
index 6c27281b62589c70492b4fad8abbffc1da5b457c..2830ea7500d951377f62cb96ae3446128739d094 100644 (file)
@@ -129,3 +129,7 @@ octeontx2-af-support-variable-number-of-lmacs.patch
 btrfs-fix-qgroup_free_reserved_data-int-overflow.patch
 btrfs-mark-the-len-field-in-struct-btrfs_ordered_sum.patch
 ring-buffer-fix-32-bit-rb_time_read-race-with-rb_tim.patch
+firewire-ohci-suppress-unexpected-system-reboot-in-amd-ryzen-machines-and-asm108x-vt630x-pcie-cards.patch
+x86-kprobes-fix-incorrect-return-address-calculation-in-kprobe_emulate_call_indirect.patch
+i2c-core-fix-atomic-xfer-check-for-non-preempt-config.patch
+mm-fix-unmap_mapping_range-high-bits-shift-bug.patch
diff --git a/queue-6.1/x86-kprobes-fix-incorrect-return-address-calculation-in-kprobe_emulate_call_indirect.patch b/queue-6.1/x86-kprobes-fix-incorrect-return-address-calculation-in-kprobe_emulate_call_indirect.patch
new file mode 100644 (file)
index 0000000..1b499cd
--- /dev/null
@@ -0,0 +1,126 @@
+From f5d03da48d062966c94f0199d20be0b3a37a7982 Mon Sep 17 00:00:00 2001
+From: Jinghao Jia <jinghao7@illinois.edu>
+Date: Tue, 2 Jan 2024 17:33:45 -0600
+Subject: x86/kprobes: fix incorrect return address calculation in kprobe_emulate_call_indirect
+
+From: Jinghao Jia <jinghao7@illinois.edu>
+
+commit f5d03da48d062966c94f0199d20be0b3a37a7982 upstream.
+
+kprobe_emulate_call_indirect currently uses int3_emulate_call to emulate
+indirect calls. However, int3_emulate_call always assumes the size of
+the call to be 5 bytes when calculating the return address. This is
+incorrect for register-based indirect calls in x86, which can be either
+2 or 3 bytes depending on whether REX prefix is used. At kprobe runtime,
+the incorrect return address causes control flow to land onto the wrong
+place after return -- possibly not a valid instruction boundary. This
+can lead to a panic like the following:
+
+[    7.308204][    C1] BUG: unable to handle page fault for address: 000000000002b4d8
+[    7.308883][    C1] #PF: supervisor read access in kernel mode
+[    7.309168][    C1] #PF: error_code(0x0000) - not-present page
+[    7.309461][    C1] PGD 0 P4D 0
+[    7.309652][    C1] Oops: 0000 [#1] SMP
+[    7.309929][    C1] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.7.0-rc5-trace-for-next #6
+[    7.310397][    C1] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-20220807_005459-localhost 04/01/2014
+[    7.311068][    C1] RIP: 0010:__common_interrupt+0x52/0xc0
+[    7.311349][    C1] Code: 01 00 4d 85 f6 74 39 49 81 fe 00 f0 ff ff 77 30 4c 89 f7 4d 8b 5e 68 41 ba 91 76 d8 42 45 03 53 fc 74 02 0f 0b cc ff d3 65 48 <8b> 05 30 c7 ff 7e 65 4c 89 3d 28 c7 ff 7e 5b 41 5c 41 5e 41 5f c3
+[    7.312512][    C1] RSP: 0018:ffffc900000e0fd0 EFLAGS: 00010046
+[    7.312899][    C1] RAX: 0000000000000001 RBX: 0000000000000023 RCX: 0000000000000001
+[    7.313334][    C1] RDX: 00000000000003cd RSI: 0000000000000001 RDI: ffff888100d302a4
+[    7.313702][    C1] RBP: 0000000000000001 R08: 0ef439818636191f R09: b1621ff338a3b482
+[    7.314146][    C1] R10: ffffffff81e5127b R11: ffffffff81059810 R12: 0000000000000023
+[    7.314509][    C1] R13: 0000000000000000 R14: ffff888100d30200 R15: 0000000000000000
+[    7.314951][    C1] FS:  0000000000000000(0000) GS:ffff88813bc80000(0000) knlGS:0000000000000000
+[    7.315396][    C1] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+[    7.315691][    C1] CR2: 000000000002b4d8 CR3: 0000000003028003 CR4: 0000000000370ef0
+[    7.316153][    C1] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+[    7.316508][    C1] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
+[    7.316948][    C1] Call Trace:
+[    7.317123][    C1]  <IRQ>
+[    7.317279][    C1]  ? __die_body+0x64/0xb0
+[    7.317482][    C1]  ? page_fault_oops+0x248/0x370
+[    7.317712][    C1]  ? __wake_up+0x96/0xb0
+[    7.317964][    C1]  ? exc_page_fault+0x62/0x130
+[    7.318211][    C1]  ? asm_exc_page_fault+0x22/0x30
+[    7.318444][    C1]  ? __cfi_native_send_call_func_single_ipi+0x10/0x10
+[    7.318860][    C1]  ? default_idle+0xb/0x10
+[    7.319063][    C1]  ? __common_interrupt+0x52/0xc0
+[    7.319330][    C1]  common_interrupt+0x78/0x90
+[    7.319546][    C1]  </IRQ>
+[    7.319679][    C1]  <TASK>
+[    7.319854][    C1]  asm_common_interrupt+0x22/0x40
+[    7.320082][    C1] RIP: 0010:default_idle+0xb/0x10
+[    7.320309][    C1] Code: 4c 01 c7 4c 29 c2 e9 72 ff ff ff cc cc cc cc 90 90 90 90 90 90 90 90 90 90 90 b8 0c 67 40 a5 66 90 0f 00 2d 09 b9 3b 00 fb f4 <fa> c3 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 b8 0c 67 40 a5 e9
+[    7.321449][    C1] RSP: 0018:ffffc9000009bee8 EFLAGS: 00000256
+[    7.321808][    C1] RAX: ffff88813bca8b68 RBX: 0000000000000001 RCX: 000000000001ef0c
+[    7.322227][    C1] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 000000000001ef0c
+[    7.322656][    C1] RBP: ffffc9000009bef8 R08: 8000000000000000 R09: 00000000000008c2
+[    7.323083][    C1] R10: 0000000000000000 R11: ffffffff81058e70 R12: 0000000000000000
+[    7.323530][    C1] R13: ffff8881002b30c0 R14: 0000000000000000 R15: 0000000000000000
+[    7.323948][    C1]  ? __cfi_lapic_next_deadline+0x10/0x10
+[    7.324239][    C1]  default_idle_call+0x31/0x50
+[    7.324464][    C1]  do_idle+0xd3/0x240
+[    7.324690][    C1]  cpu_startup_entry+0x25/0x30
+[    7.324983][    C1]  start_secondary+0xb4/0xc0
+[    7.325217][    C1]  secondary_startup_64_no_verify+0x179/0x17b
+[    7.325498][    C1]  </TASK>
+[    7.325641][    C1] Modules linked in:
+[    7.325906][    C1] CR2: 000000000002b4d8
+[    7.326104][    C1] ---[ end trace 0000000000000000 ]---
+[    7.326354][    C1] RIP: 0010:__common_interrupt+0x52/0xc0
+[    7.326614][    C1] Code: 01 00 4d 85 f6 74 39 49 81 fe 00 f0 ff ff 77 30 4c 89 f7 4d 8b 5e 68 41 ba 91 76 d8 42 45 03 53 fc 74 02 0f 0b cc ff d3 65 48 <8b> 05 30 c7 ff 7e 65 4c 89 3d 28 c7 ff 7e 5b 41 5c 41 5e 41 5f c3
+[    7.327570][    C1] RSP: 0018:ffffc900000e0fd0 EFLAGS: 00010046
+[    7.327910][    C1] RAX: 0000000000000001 RBX: 0000000000000023 RCX: 0000000000000001
+[    7.328273][    C1] RDX: 00000000000003cd RSI: 0000000000000001 RDI: ffff888100d302a4
+[    7.328632][    C1] RBP: 0000000000000001 R08: 0ef439818636191f R09: b1621ff338a3b482
+[    7.329223][    C1] R10: ffffffff81e5127b R11: ffffffff81059810 R12: 0000000000000023
+[    7.329780][    C1] R13: 0000000000000000 R14: ffff888100d30200 R15: 0000000000000000
+[    7.330193][    C1] FS:  0000000000000000(0000) GS:ffff88813bc80000(0000) knlGS:0000000000000000
+[    7.330632][    C1] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+[    7.331050][    C1] CR2: 000000000002b4d8 CR3: 0000000003028003 CR4: 0000000000370ef0
+[    7.331454][    C1] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+[    7.331854][    C1] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
+[    7.332236][    C1] Kernel panic - not syncing: Fatal exception in interrupt
+[    7.332730][    C1] Kernel Offset: disabled
+[    7.333044][    C1] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---
+
+The relevant assembly code is (from objdump, faulting address
+highlighted):
+
+ffffffff8102ed9d:       41 ff d3                  call   *%r11
+ffffffff8102eda0:       65 48 <8b> 05 30 c7 ff    mov    %gs:0x7effc730(%rip),%rax
+
+The emulation incorrectly sets the return address to be ffffffff8102ed9d
++ 0x5 = ffffffff8102eda2, which is the 8b byte in the middle of the next
+mov. This in turn causes incorrect subsequent instruction decoding and
+eventually triggers the page fault above.
+
+Instead of invoking int3_emulate_call, perform push and jmp emulation
+directly in kprobe_emulate_call_indirect. At this point we can obtain
+the instruction size from p->ainsn.size so that we can calculate the
+correct return address.
+
+Link: https://lore.kernel.org/all/20240102233345.385475-1-jinghao7@illinois.edu/
+
+Fixes: 6256e668b7af ("x86/kprobes: Use int3 instead of debug trap for single-step")
+Cc: stable@vger.kernel.org
+Signed-off-by: Jinghao Jia <jinghao7@illinois.edu>
+Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/kprobes/core.c |    3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/arch/x86/kernel/kprobes/core.c
++++ b/arch/x86/kernel/kprobes/core.c
+@@ -549,7 +549,8 @@ static void kprobe_emulate_call_indirect
+ {
+       unsigned long offs = addrmode_regoffs[p->ainsn.indirect.reg];
+-      int3_emulate_call(regs, regs_get_register(regs, offs));
++      int3_emulate_push(regs, regs->ip - INT3_INSN_SIZE + p->ainsn.size);
++      int3_emulate_jmp(regs, regs_get_register(regs, offs));
+ }
+ NOKPROBE_SYMBOL(kprobe_emulate_call_indirect);