From: Greg Kroah-Hartman Date: Wed, 22 Nov 2023 17:28:52 +0000 (+0000) Subject: 5.10-stable patches X-Git-Tag: v4.14.331~131 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=73b746a95d1870817b4aae554b3f75b361bfdbe1;p=thirdparty%2Fkernel%2Fstable-queue.git 5.10-stable patches added patches: audit-don-t-take-task_lock-in-audit_exe_compare-code-path.patch audit-don-t-warn_on_once-current-mm-in-audit_exe_compare.patch hvc-xen-fix-console-unplug.patch hvc-xen-fix-error-path-in-xen_hvc_init-to-always-register-frontend-driver.patch pci-sysfs-protect-driver-s-d3cold-preference-from-user-space.patch tty-sysrq-replace-smp_processor_id-with-get_cpu.patch --- diff --git a/queue-5.10/audit-don-t-take-task_lock-in-audit_exe_compare-code-path.patch b/queue-5.10/audit-don-t-take-task_lock-in-audit_exe_compare-code-path.patch new file mode 100644 index 00000000000..18c82481c05 --- /dev/null +++ b/queue-5.10/audit-don-t-take-task_lock-in-audit_exe_compare-code-path.patch @@ -0,0 +1,61 @@ +From 47846d51348dd62e5231a83be040981b17c955fa Mon Sep 17 00:00:00 2001 +From: Paul Moore +Date: Mon, 9 Oct 2023 13:18:49 -0400 +Subject: audit: don't take task_lock() in audit_exe_compare() code path + +From: Paul Moore + +commit 47846d51348dd62e5231a83be040981b17c955fa upstream. + +The get_task_exe_file() function locks the given task with task_lock() +which when used inside audit_exe_compare() can cause deadlocks on +systems that generate audit records when the task_lock() is held. We +resolve this problem with two changes: ignoring those cases where the +task being audited is not the current task, and changing our approach +to obtaining the executable file struct to not require task_lock(). + +With the intent of the audit exe filter being to filter on audit events +generated by processes started by the specified executable, it makes +sense that we would only want to use the exe filter on audit records +associated with the currently executing process, e.g. @current. If +we are asked to filter records using a non-@current task_struct we can +safely ignore the exe filter without negatively impacting the admin's +expectations for the exe filter. + +Knowing that we only have to worry about filtering the currently +executing task in audit_exe_compare() we can do away with the +task_lock() and call get_mm_exe_file() with @current->mm directly. + +Cc: +Fixes: 5efc244346f9 ("audit: fix exe_file access in audit_exe_compare") +Reported-by: Andreas Steinmetz +Reviewed-by: John Johansen +Reviewed-by: Mateusz Guzik +Signed-off-by: Paul Moore +Signed-off-by: Greg Kroah-Hartman +--- + kernel/audit_watch.c | 9 ++++++++- + 1 file changed, 8 insertions(+), 1 deletion(-) + +--- a/kernel/audit_watch.c ++++ b/kernel/audit_watch.c +@@ -527,11 +527,18 @@ int audit_exe_compare(struct task_struct + unsigned long ino; + dev_t dev; + +- exe_file = get_task_exe_file(tsk); ++ /* only do exe filtering if we are recording @current events/records */ ++ if (tsk != current) ++ return 0; ++ ++ if (WARN_ON_ONCE(!current->mm)) ++ return 0; ++ exe_file = get_mm_exe_file(current->mm); + if (!exe_file) + return 0; + ino = file_inode(exe_file)->i_ino; + dev = file_inode(exe_file)->i_sb->s_dev; + fput(exe_file); ++ + return audit_mark_compare(mark, ino, dev); + } diff --git a/queue-5.10/audit-don-t-warn_on_once-current-mm-in-audit_exe_compare.patch b/queue-5.10/audit-don-t-warn_on_once-current-mm-in-audit_exe_compare.patch new file mode 100644 index 00000000000..3b3298e4aa3 --- /dev/null +++ b/queue-5.10/audit-don-t-warn_on_once-current-mm-in-audit_exe_compare.patch @@ -0,0 +1,37 @@ +From 969d90ec212bae4b45bf9d21d7daa30aa6cf055e Mon Sep 17 00:00:00 2001 +From: Paul Moore +Date: Tue, 14 Nov 2023 17:25:48 -0500 +Subject: audit: don't WARN_ON_ONCE(!current->mm) in audit_exe_compare() + +From: Paul Moore + +commit 969d90ec212bae4b45bf9d21d7daa30aa6cf055e upstream. + +eBPF can end up calling into the audit code from some odd places, and +some of these places don't have @current set properly so we end up +tripping the `WARN_ON_ONCE(!current->mm)` near the top of +`audit_exe_compare()`. While the basic `!current->mm` check is good, +the `WARN_ON_ONCE()` results in some scary console messages so let's +drop that and just do the regular `!current->mm` check to avoid +problems. + +Cc: +Fixes: 47846d51348d ("audit: don't take task_lock() in audit_exe_compare() code path") +Reported-by: Artem Savkov +Signed-off-by: Paul Moore +Signed-off-by: Greg Kroah-Hartman +--- + kernel/audit_watch.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/kernel/audit_watch.c ++++ b/kernel/audit_watch.c +@@ -531,7 +531,7 @@ int audit_exe_compare(struct task_struct + if (tsk != current) + return 0; + +- if (WARN_ON_ONCE(!current->mm)) ++ if (!current->mm) + return 0; + exe_file = get_mm_exe_file(current->mm); + if (!exe_file) diff --git a/queue-5.10/hvc-xen-fix-console-unplug.patch b/queue-5.10/hvc-xen-fix-console-unplug.patch new file mode 100644 index 00000000000..6464573ef34 --- /dev/null +++ b/queue-5.10/hvc-xen-fix-console-unplug.patch @@ -0,0 +1,121 @@ +From a30badfd7c13fc8763a9e10c5a12ba7f81515a55 Mon Sep 17 00:00:00 2001 +From: David Woodhouse +Date: Fri, 20 Oct 2023 17:15:29 +0100 +Subject: hvc/xen: fix console unplug + +From: David Woodhouse + +commit a30badfd7c13fc8763a9e10c5a12ba7f81515a55 upstream. + +On unplug of a Xen console, xencons_disconnect_backend() unconditionally +calls free_irq() via unbind_from_irqhandler(), causing a warning of +freeing an already-free IRQ: + +(qemu) device_del con1 +[ 32.050919] ------------[ cut here ]------------ +[ 32.050942] Trying to free already-free IRQ 33 +[ 32.050990] WARNING: CPU: 0 PID: 51 at kernel/irq/manage.c:1895 __free_irq+0x1d4/0x330 + +It should be using evtchn_put() to tear down the event channel binding, +and let the Linux IRQ side of it be handled by notifier_del_irq() through +the HVC code. + +On which topic... xencons_disconnect_backend() should call hvc_remove() +*first*, rather than tearing down the event channel and grant mapping +while they are in use. And then the IRQ is guaranteed to be freed by +the time it's torn down by evtchn_put(). + +Since evtchn_put() also closes the actual event channel, avoid calling +xenbus_free_evtchn() except in the failure path where the IRQ was not +successfully set up. + +However, calling hvc_remove() at the start of xencons_disconnect_backend() +still isn't early enough. An unplug request is indicated by the backend +setting its state to XenbusStateClosing, which triggers a notification +to xencons_backend_changed(), which... does nothing except set its own +frontend state directly to XenbusStateClosed without *actually* tearing +down the HVC device or, you know, making sure it isn't actively in use. + +So the backend sees the guest frontend set its state to XenbusStateClosed +and stops servicing the interrupt... and the guest spins for ever in the +domU_write_console() function waiting for the ring to drain. + +Fix that one by calling hvc_remove() from xencons_backend_changed() before +signalling to the backend that it's OK to proceed with the removal. + +Tested with 'dd if=/dev/zero of=/dev/hvc1' while telling Qemu to remove +the console device. + +Signed-off-by: David Woodhouse +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20231020161529.355083-4-dwmw2@infradead.org +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Greg Kroah-Hartman +--- + drivers/tty/hvc/hvc_xen.c | 32 ++++++++++++++++++++++++-------- + 1 file changed, 24 insertions(+), 8 deletions(-) + +--- a/drivers/tty/hvc/hvc_xen.c ++++ b/drivers/tty/hvc/hvc_xen.c +@@ -363,18 +363,21 @@ void xen_console_resume(void) + #ifdef CONFIG_HVC_XEN_FRONTEND + static void xencons_disconnect_backend(struct xencons_info *info) + { +- if (info->irq > 0) +- unbind_from_irqhandler(info->irq, NULL); +- info->irq = 0; ++ if (info->hvc != NULL) ++ hvc_remove(info->hvc); ++ info->hvc = NULL; ++ if (info->irq > 0) { ++ evtchn_put(info->evtchn); ++ info->irq = 0; ++ info->evtchn = 0; ++ } ++ /* evtchn_put() will also close it so this is only an error path */ + if (info->evtchn > 0) + xenbus_free_evtchn(info->xbdev, info->evtchn); + info->evtchn = 0; + if (info->gntref > 0) + gnttab_free_grant_references(info->gntref); + info->gntref = 0; +- if (info->hvc != NULL) +- hvc_remove(info->hvc); +- info->hvc = NULL; + } + + static void xencons_free(struct xencons_info *info) +@@ -538,10 +541,23 @@ static void xencons_backend_changed(stru + if (dev->state == XenbusStateClosed) + break; + fallthrough; /* Missed the backend's CLOSING state */ +- case XenbusStateClosing: ++ case XenbusStateClosing: { ++ struct xencons_info *info = dev_get_drvdata(&dev->dev);; ++ ++ /* ++ * Don't tear down the evtchn and grant ref before the other ++ * end has disconnected, but do stop userspace from trying ++ * to use the device before we allow the backend to close. ++ */ ++ if (info->hvc) { ++ hvc_remove(info->hvc); ++ info->hvc = NULL; ++ } ++ + xenbus_frontend_closed(dev); + break; + } ++ } + } + + static const struct xenbus_device_id xencons_ids[] = { +@@ -600,7 +616,7 @@ static int __init xen_hvc_init(void) + list_del(&info->list); + spin_unlock_irqrestore(&xencons_lock, flags); + if (info->irq) +- unbind_from_irqhandler(info->irq, NULL); ++ evtchn_put(info->evtchn); + kfree(info); + return r; + } diff --git a/queue-5.10/hvc-xen-fix-error-path-in-xen_hvc_init-to-always-register-frontend-driver.patch b/queue-5.10/hvc-xen-fix-error-path-in-xen_hvc_init-to-always-register-frontend-driver.patch new file mode 100644 index 00000000000..876d9ebea78 --- /dev/null +++ b/queue-5.10/hvc-xen-fix-error-path-in-xen_hvc_init-to-always-register-frontend-driver.patch @@ -0,0 +1,54 @@ +From 2704c9a5593f4a47620c12dad78838ca62b52f48 Mon Sep 17 00:00:00 2001 +From: David Woodhouse +Date: Fri, 20 Oct 2023 17:15:28 +0100 +Subject: hvc/xen: fix error path in xen_hvc_init() to always register frontend driver +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: David Woodhouse + +commit 2704c9a5593f4a47620c12dad78838ca62b52f48 upstream. + +The xen_hvc_init() function should always register the frontend driver, +even when there's no primary console — as there may be secondary consoles. +(Qemu can always add secondary consoles, but only the toolstack can add +the primary because it's special.) + +Signed-off-by: David Woodhouse +Reviewed-by: Juergen Gross +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20231020161529.355083-3-dwmw2@infradead.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/tty/hvc/hvc_xen.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +--- a/drivers/tty/hvc/hvc_xen.c ++++ b/drivers/tty/hvc/hvc_xen.c +@@ -588,7 +588,7 @@ static int __init xen_hvc_init(void) + ops = &dom0_hvc_ops; + r = xen_initial_domain_console_init(); + if (r < 0) +- return r; ++ goto register_fe; + info = vtermno_to_xencons(HVC_COOKIE); + } else { + ops = &domU_hvc_ops; +@@ -597,7 +597,7 @@ static int __init xen_hvc_init(void) + else + r = xen_pv_console_init(); + if (r < 0) +- return r; ++ goto register_fe; + + info = vtermno_to_xencons(HVC_COOKIE); + info->irq = bind_evtchn_to_irq_lateeoi(info->evtchn); +@@ -622,6 +622,7 @@ static int __init xen_hvc_init(void) + } + + r = 0; ++ register_fe: + #ifdef CONFIG_HVC_XEN_FRONTEND + r = xenbus_register_frontend(&xencons_driver); + #endif diff --git a/queue-5.10/pci-sysfs-protect-driver-s-d3cold-preference-from-user-space.patch b/queue-5.10/pci-sysfs-protect-driver-s-d3cold-preference-from-user-space.patch new file mode 100644 index 00000000000..5ddb7b90977 --- /dev/null +++ b/queue-5.10/pci-sysfs-protect-driver-s-d3cold-preference-from-user-space.patch @@ -0,0 +1,69 @@ +From 70b70a4307cccebe91388337b1c85735ce4de6ff Mon Sep 17 00:00:00 2001 +From: Lukas Wunner +Date: Mon, 18 Sep 2023 14:48:01 +0200 +Subject: PCI/sysfs: Protect driver's D3cold preference from user space + +From: Lukas Wunner + +commit 70b70a4307cccebe91388337b1c85735ce4de6ff upstream. + +struct pci_dev contains two flags which govern whether the device may +suspend to D3cold: + +* no_d3cold provides an opt-out for drivers (e.g. if a device is known + to not wake from D3cold) + +* d3cold_allowed provides an opt-out for user space (default is true, + user space may set to false) + +Since commit 9d26d3a8f1b0 ("PCI: Put PCIe ports into D3 during suspend"), +the user space setting overwrites the driver setting. Essentially user +space is trusted to know better than the driver whether D3cold is +working. + +That feels unsafe and wrong. Assume that the change was introduced +inadvertently and do not overwrite no_d3cold when d3cold_allowed is +modified. Instead, consider d3cold_allowed in addition to no_d3cold +when choosing a suspend state for the device. + +That way, user space may opt out of D3cold if the driver hasn't, but it +may no longer force an opt in if the driver has opted out. + +Fixes: 9d26d3a8f1b0 ("PCI: Put PCIe ports into D3 during suspend") +Link: https://lore.kernel.org/r/b8a7f4af2b73f6b506ad8ddee59d747cbf834606.1695025365.git.lukas@wunner.de +Signed-off-by: Lukas Wunner +Signed-off-by: Bjorn Helgaas +Reviewed-by: Mika Westerberg +Reviewed-by: Mario Limonciello +Cc: stable@vger.kernel.org # v4.8+ +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pci/pci-acpi.c | 2 +- + drivers/pci/pci-sysfs.c | 5 +---- + 2 files changed, 2 insertions(+), 5 deletions(-) + +--- a/drivers/pci/pci-acpi.c ++++ b/drivers/pci/pci-acpi.c +@@ -909,7 +909,7 @@ static pci_power_t acpi_pci_choose_state + { + int acpi_state, d_max; + +- if (pdev->no_d3cold) ++ if (pdev->no_d3cold || !pdev->d3cold_allowed) + d_max = ACPI_STATE_D3_HOT; + else + d_max = ACPI_STATE_D3_COLD; +--- a/drivers/pci/pci-sysfs.c ++++ b/drivers/pci/pci-sysfs.c +@@ -500,10 +500,7 @@ static ssize_t d3cold_allowed_store(stru + return -EINVAL; + + pdev->d3cold_allowed = !!val; +- if (pdev->d3cold_allowed) +- pci_d3cold_enable(pdev); +- else +- pci_d3cold_disable(pdev); ++ pci_bridge_d3_update(pdev); + + pm_runtime_resume(dev); + diff --git a/queue-5.10/series b/queue-5.10/series index 1a2602a6c2b..8a425962f2f 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -96,3 +96,9 @@ scsi-megaraid_sas-increase-register-read-retry-rount-from-3-to-30-for-selected-r x86-cpu-hygon-fix-the-cpu-topology-evaluation-for-real.patch kvm-x86-hyper-v-don-t-auto-enable-stimer-on-write-from-user-space.patch kvm-x86-ignore-msr_amd64_tw_cfg-access.patch +audit-don-t-take-task_lock-in-audit_exe_compare-code-path.patch +audit-don-t-warn_on_once-current-mm-in-audit_exe_compare.patch +tty-sysrq-replace-smp_processor_id-with-get_cpu.patch +hvc-xen-fix-console-unplug.patch +hvc-xen-fix-error-path-in-xen_hvc_init-to-always-register-frontend-driver.patch +pci-sysfs-protect-driver-s-d3cold-preference-from-user-space.patch diff --git a/queue-5.10/tty-sysrq-replace-smp_processor_id-with-get_cpu.patch b/queue-5.10/tty-sysrq-replace-smp_processor_id-with-get_cpu.patch new file mode 100644 index 00000000000..62ef5a8f081 --- /dev/null +++ b/queue-5.10/tty-sysrq-replace-smp_processor_id-with-get_cpu.patch @@ -0,0 +1,72 @@ +From dd976a97d15b47656991e185a94ef42a0fa5cfd4 Mon Sep 17 00:00:00 2001 +From: Muhammad Usama Anjum +Date: Mon, 9 Oct 2023 21:20:20 +0500 +Subject: tty/sysrq: replace smp_processor_id() with get_cpu() + +From: Muhammad Usama Anjum + +commit dd976a97d15b47656991e185a94ef42a0fa5cfd4 upstream. + +The smp_processor_id() shouldn't be called from preemptible code. +Instead use get_cpu() and put_cpu() which disables preemption in +addition to getting the processor id. Enable preemption back after +calling schedule_work() to make sure that the work gets scheduled on all +cores other than the current core. We want to avoid a scenario where +current core's stack trace is printed multiple times and one core's +stack trace isn't printed because of scheduling of current task. + +This fixes the following bug: + +[ 119.143590] sysrq: Show backtrace of all active CPUs +[ 119.143902] BUG: using smp_processor_id() in preemptible [00000000] code: bash/873 +[ 119.144586] caller is debug_smp_processor_id+0x20/0x30 +[ 119.144827] CPU: 6 PID: 873 Comm: bash Not tainted 5.10.124-dirty #3 +[ 119.144861] Hardware name: QEMU QEMU Virtual Machine, BIOS 2023.05-1 07/22/2023 +[ 119.145053] Call trace: +[ 119.145093] dump_backtrace+0x0/0x1a0 +[ 119.145122] show_stack+0x18/0x70 +[ 119.145141] dump_stack+0xc4/0x11c +[ 119.145159] check_preemption_disabled+0x100/0x110 +[ 119.145175] debug_smp_processor_id+0x20/0x30 +[ 119.145195] sysrq_handle_showallcpus+0x20/0xc0 +[ 119.145211] __handle_sysrq+0x8c/0x1a0 +[ 119.145227] write_sysrq_trigger+0x94/0x12c +[ 119.145247] proc_reg_write+0xa8/0xe4 +[ 119.145266] vfs_write+0xec/0x280 +[ 119.145282] ksys_write+0x6c/0x100 +[ 119.145298] __arm64_sys_write+0x20/0x30 +[ 119.145315] el0_svc_common.constprop.0+0x78/0x1e4 +[ 119.145332] do_el0_svc+0x24/0x8c +[ 119.145348] el0_svc+0x10/0x20 +[ 119.145364] el0_sync_handler+0x134/0x140 +[ 119.145381] el0_sync+0x180/0x1c0 + +Cc: jirislaby@kernel.org +Cc: stable@vger.kernel.org +Fixes: 47cab6a722d4 ("debug lockups: Improve lockup detection, fix generic arch fallback") +Signed-off-by: Muhammad Usama Anjum +Link: https://lore.kernel.org/r/20231009162021.3607632-1-usama.anjum@collabora.com +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Greg Kroah-Hartman +--- + drivers/tty/sysrq.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/tty/sysrq.c ++++ b/drivers/tty/sysrq.c +@@ -262,13 +262,14 @@ static void sysrq_handle_showallcpus(int + if (in_irq()) + regs = get_irq_regs(); + +- pr_info("CPU%d:\n", smp_processor_id()); ++ pr_info("CPU%d:\n", get_cpu()); + if (regs) + show_regs(regs); + else + show_stack(NULL, NULL, KERN_INFO); + + schedule_work(&sysrq_showallcpus); ++ put_cpu(); + } + } +