From: Greg Kroah-Hartman Date: Mon, 8 Jan 2024 12:40:15 +0000 (+0100) Subject: 5.10-stable patches X-Git-Tag: v4.14.336~20 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=f7a847c3392f8307c2cc14598daee245bc29e848;p=thirdparty%2Fkernel%2Fstable-queue.git 5.10-stable patches 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 --- diff --git a/queue-5.10/firewire-ohci-suppress-unexpected-system-reboot-in-amd-ryzen-machines-and-asm108x-vt630x-pcie-cards.patch b/queue-5.10/firewire-ohci-suppress-unexpected-system-reboot-in-amd-ryzen-machines-and-asm108x-vt630x-pcie-cards.patch new file mode 100644 index 00000000000..d6ca812ef69 --- /dev/null +++ b/queue-5.10/firewire-ohci-suppress-unexpected-system-reboot-in-amd-ryzen-machines-and-asm108x-vt630x-pcie-cards.patch @@ -0,0 +1,125 @@ +From ac9184fbb8478dab4a0724b279f94956b69be827 Mon Sep 17 00:00:00 2001 +From: Takashi Sakamoto +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 + +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 +Closes: https://bugzilla.suse.com/show_bug.cgi?id=1215436 +Reported-by: Mario Limonciello +Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217994 +Reported-by: Tobias Gruetzmacher +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 +Signed-off-by: Greg Kroah-Hartman +--- + 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-5.10/i2c-core-fix-atomic-xfer-check-for-non-preempt-config.patch b/queue-5.10/i2c-core-fix-atomic-xfer-check-for-non-preempt-config.patch new file mode 100644 index 00000000000..89d09b9a19a --- /dev/null +++ b/queue-5.10/i2c-core-fix-atomic-xfer-check-for-non-preempt-config.patch @@ -0,0 +1,59 @@ +From a3368e1186e3ce8e38f78cbca019622095b1f331 Mon Sep 17 00:00:00 2001 +From: Benjamin Bara +Date: Thu, 4 Jan 2024 09:17:08 +0100 +Subject: i2c: core: Fix atomic xfer check for non-preempt config + +From: Benjamin Bara + +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 +Tested-by: Michael Walle +Tested-by: Tor Vic +[wsa: removed a comment which needs more work, code is ok] +Signed-off-by: Wolfram Sang +Signed-off-by: Greg Kroah-Hartman +--- + 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 + #include + + 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-5.10/mm-fix-unmap_mapping_range-high-bits-shift-bug.patch b/queue-5.10/mm-fix-unmap_mapping_range-high-bits-shift-bug.patch new file mode 100644 index 00000000000..01c255bb121 --- /dev/null +++ b/queue-5.10/mm-fix-unmap_mapping_range-high-bits-shift-bug.patch @@ -0,0 +1,81 @@ +From 9eab0421fa94a3dde0d1f7e36ab3294fc306c99d Mon Sep 17 00:00:00 2001 +From: Jiajun Xie +Date: Wed, 20 Dec 2023 13:28:39 +0800 +Subject: mm: fix unmap_mapping_range high bits shift bug + +From: Jiajun Xie + +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 +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + mm/memory.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/mm/memory.c ++++ b/mm/memory.c +@@ -3300,8 +3300,8 @@ void unmap_mapping_pages(struct address_ + 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)) { diff --git a/queue-5.10/series b/queue-5.10/series index d797c42567f..cfe0e131191 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -25,3 +25,7 @@ asix-add-check-for-usbnet_get_endpoints.patch bnxt_en-remove-mis-applied-code-from-bnxt_cfg_ntp_fi.patch net-implement-missing-so_timestamping_new-cmsg-suppo.patch mm-memory-failure-check-the-mapcount-of-the-precise-.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-5.10/x86-kprobes-fix-incorrect-return-address-calculation-in-kprobe_emulate_call_indirect.patch b/queue-5.10/x86-kprobes-fix-incorrect-return-address-calculation-in-kprobe_emulate_call_indirect.patch new file mode 100644 index 00000000000..37e91b0cbd2 --- /dev/null +++ b/queue-5.10/x86-kprobes-fix-incorrect-return-address-calculation-in-kprobe_emulate_call_indirect.patch @@ -0,0 +1,126 @@ +From f5d03da48d062966c94f0199d20be0b3a37a7982 Mon Sep 17 00:00:00 2001 +From: Jinghao Jia +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 + +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] +[ 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] +[ 7.319679][ C1] +[ 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 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] +[ 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 +Signed-off-by: Masami Hiramatsu (Google) +Signed-off-by: Greg Kroah-Hartman +--- + 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 +@@ -569,7 +569,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); +