From: Greg Kroah-Hartman Date: Sun, 28 May 2023 16:52:29 +0000 (+0100) Subject: 4.14-stable patches X-Git-Tag: review~15 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=2fa87ada62b695df60385abb446c6bc55a80cf14;p=thirdparty%2Fkernel%2Fstable-queue.git 4.14-stable patches added patches: forcedeth-fix-an-error-handling-path-in-nv_probe.patch x86-show_trace_log_lvl-ensure-stack-pointer-is-aligned-again.patch --- diff --git a/queue-4.14/forcedeth-fix-an-error-handling-path-in-nv_probe.patch b/queue-4.14/forcedeth-fix-an-error-handling-path-in-nv_probe.patch new file mode 100644 index 00000000000..49be22b22f3 --- /dev/null +++ b/queue-4.14/forcedeth-fix-an-error-handling-path-in-nv_probe.patch @@ -0,0 +1,35 @@ +From 5b17a4971d3b2a073f4078dd65331efbe35baa2d Mon Sep 17 00:00:00 2001 +From: Christophe JAILLET +Date: Sat, 20 May 2023 10:30:17 +0200 +Subject: forcedeth: Fix an error handling path in nv_probe() + +From: Christophe JAILLET + +commit 5b17a4971d3b2a073f4078dd65331efbe35baa2d upstream. + +If an error occures after calling nv_mgmt_acquire_sema(), it should be +undone with a corresponding nv_mgmt_release_sema() call. + +Add it in the error handling path of the probe as already done in the +remove function. + +Fixes: cac1c52c3621 ("forcedeth: mgmt unit interface") +Signed-off-by: Christophe JAILLET +Acked-by: Zhu Yanjun +Link: https://lore.kernel.org/r/355e9a7d351b32ad897251b6f81b5886fcdc6766.1684571393.git.christophe.jaillet@wanadoo.fr +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/nvidia/forcedeth.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/net/ethernet/nvidia/forcedeth.c ++++ b/drivers/net/ethernet/nvidia/forcedeth.c +@@ -6020,6 +6020,7 @@ static int nv_probe(struct pci_dev *pci_ + return 0; + + out_error: ++ nv_mgmt_release_sema(dev); + if (phystate_orig) + writel(phystate|NVREG_ADAPTCTL_RUNNING, base + NvRegAdapterControl); + out_freering: diff --git a/queue-4.14/series b/queue-4.14/series index 3c6705660c2..2fae2392689 100644 --- a/queue-4.14/series +++ b/queue-4.14/series @@ -81,3 +81,5 @@ power-supply-bq27xxx-fix-i2c-irq-race-on-remove.patch power-supply-bq27xxx-fix-poll_interval-handling-and-races-on-remove.patch power-supply-sbs-charger-fix-inhibited-bit-for-status-reg.patch xen-pvcalls-back-fix-double-frees-with-pvcalls_new_active_socket.patch +x86-show_trace_log_lvl-ensure-stack-pointer-is-aligned-again.patch +forcedeth-fix-an-error-handling-path-in-nv_probe.patch diff --git a/queue-4.14/x86-show_trace_log_lvl-ensure-stack-pointer-is-aligned-again.patch b/queue-4.14/x86-show_trace_log_lvl-ensure-stack-pointer-is-aligned-again.patch new file mode 100644 index 00000000000..1f35446eaa5 --- /dev/null +++ b/queue-4.14/x86-show_trace_log_lvl-ensure-stack-pointer-is-aligned-again.patch @@ -0,0 +1,69 @@ +From 2e4be0d011f21593c6b316806779ba1eba2cd7e0 Mon Sep 17 00:00:00 2001 +From: Vernon Lovejoy +Date: Fri, 12 May 2023 12:42:32 +0200 +Subject: x86/show_trace_log_lvl: Ensure stack pointer is aligned, again + +From: Vernon Lovejoy + +commit 2e4be0d011f21593c6b316806779ba1eba2cd7e0 upstream. + +The commit e335bb51cc15 ("x86/unwind: Ensure stack pointer is aligned") +tried to align the stack pointer in show_trace_log_lvl(), otherwise the +"stack < stack_info.end" check can't guarantee that the last read does +not go past the end of the stack. + +However, we have the same problem with the initial value of the stack +pointer, it can also be unaligned. So without this patch this trivial +kernel module + + #include + + static int init(void) + { + asm volatile("sub $0x4,%rsp"); + dump_stack(); + asm volatile("add $0x4,%rsp"); + + return -EAGAIN; + } + + module_init(init); + MODULE_LICENSE("GPL"); + +crashes the kernel. + +Fixes: e335bb51cc15 ("x86/unwind: Ensure stack pointer is aligned") +Signed-off-by: Vernon Lovejoy +Signed-off-by: Oleg Nesterov +Link: https://lore.kernel.org/r/20230512104232.GA10227@redhat.com +Signed-off-by: Josh Poimboeuf +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kernel/dumpstack.c | 7 +++++-- + 1 file changed, 5 insertions(+), 2 deletions(-) + +--- a/arch/x86/kernel/dumpstack.c ++++ b/arch/x86/kernel/dumpstack.c +@@ -115,7 +115,6 @@ void show_trace_log_lvl(struct task_stru + printk("%sCall Trace:\n", log_lvl); + + unwind_start(&state, task, regs, stack); +- stack = stack ? : get_stack_pointer(task, regs); + regs = unwind_get_entry_regs(&state, &partial); + + /* +@@ -134,9 +133,13 @@ void show_trace_log_lvl(struct task_stru + * - hardirq stack + * - entry stack + */ +- for ( ; stack; stack = PTR_ALIGN(stack_info.next_sp, sizeof(long))) { ++ for (stack = stack ?: get_stack_pointer(task, regs); ++ stack; ++ stack = stack_info.next_sp) { + const char *stack_name; + ++ stack = PTR_ALIGN(stack, sizeof(long)); ++ + if (get_stack_info(stack, task, &stack_info, &visit_mask)) { + /* + * We weren't on a valid stack. It's possible that