--- /dev/null
+From 47846d51348dd62e5231a83be040981b17c955fa Mon Sep 17 00:00:00 2001
+From: Paul Moore <paul@paul-moore.com>
+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 <paul@paul-moore.com>
+
+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: <stable@vger.kernel.org>
+Fixes: 5efc244346f9 ("audit: fix exe_file access in audit_exe_compare")
+Reported-by: Andreas Steinmetz <anstein99@googlemail.com>
+Reviewed-by: John Johansen <john.johanse@canonical.com>
+Reviewed-by: Mateusz Guzik <mjguzik@gmail.com>
+Signed-off-by: Paul Moore <paul@paul-moore.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
+ }
--- /dev/null
+From 969d90ec212bae4b45bf9d21d7daa30aa6cf055e Mon Sep 17 00:00:00 2001
+From: Paul Moore <paul@paul-moore.com>
+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 <paul@paul-moore.com>
+
+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: <stable@vger.kernel.org>
+Fixes: 47846d51348d ("audit: don't take task_lock() in audit_exe_compare() code path")
+Reported-by: Artem Savkov <asavkov@redhat.com>
+Signed-off-by: Paul Moore <paul@paul-moore.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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)
--- /dev/null
+From a30badfd7c13fc8763a9e10c5a12ba7f81515a55 Mon Sep 17 00:00:00 2001
+From: David Woodhouse <dwmw@amazon.co.uk>
+Date: Fri, 20 Oct 2023 17:15:29 +0100
+Subject: hvc/xen: fix console unplug
+
+From: David Woodhouse <dwmw@amazon.co.uk>
+
+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 <dwmw@amazon.co.uk>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20231020161529.355083-4-dwmw2@infradead.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+@@ -377,18 +377,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)
+@@ -553,10 +556,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[] = {
+@@ -615,7 +631,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;
+ }
--- /dev/null
+From 2704c9a5593f4a47620c12dad78838ca62b52f48 Mon Sep 17 00:00:00 2001
+From: David Woodhouse <dwmw@amazon.co.uk>
+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 <dwmw@amazon.co.uk>
+
+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 <dwmw@amazon.co.uk>
+Reviewed-by: Juergen Gross <jgross@suse.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20231020161529.355083-3-dwmw2@infradead.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+@@ -603,7 +603,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;
+@@ -612,7 +612,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);
+@@ -637,6 +637,7 @@ static int __init xen_hvc_init(void)
+ }
+
+ r = 0;
++ register_fe:
+ #ifdef CONFIG_HVC_XEN_FRONTEND
+ r = xenbus_register_frontend(&xencons_driver);
+ #endif
--- /dev/null
+From ef5dd8ec88ac11e8e353164407d55b73c988b369 Mon Sep 17 00:00:00 2001
+From: David Woodhouse <dwmw@amazon.co.uk>
+Date: Fri, 20 Oct 2023 17:15:27 +0100
+Subject: hvc/xen: fix event channel handling for secondary consoles
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: David Woodhouse <dwmw@amazon.co.uk>
+
+commit ef5dd8ec88ac11e8e353164407d55b73c988b369 upstream.
+
+The xencons_connect_backend() function allocates a local interdomain
+event channel with xenbus_alloc_evtchn(), then calls
+bind_interdomain_evtchn_to_irq_lateeoi() to bind to that port# on the
+*remote* domain.
+
+That doesn't work very well:
+
+(qemu) device_add xen-console,id=con1,chardev=pty0
+[ 44.323872] xenconsole console-1: 2 xenbus_dev_probe on device/console/1
+[ 44.323995] xenconsole: probe of console-1 failed with error -2
+
+Fix it to use bind_evtchn_to_irq_lateeoi(), which does the right thing
+by just binding that *local* event channel to an irq. The backend will
+do the interdomain binding.
+
+This didn't affect the primary console because the setup for that is
+special — the toolstack allocates the guest event channel and the guest
+discovers it with HVMOP_get_param.
+
+Fixes: fe415186b43d ("xen/console: harden hvc_xen against event channel storms")
+Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
+Reviewed-by: Juergen Gross <jgross@suse.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20231020161529.355083-2-dwmw2@infradead.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/hvc/hvc_xen.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/tty/hvc/hvc_xen.c
++++ b/drivers/tty/hvc/hvc_xen.c
+@@ -436,7 +436,7 @@ static int xencons_connect_backend(struc
+ if (ret)
+ return ret;
+ info->evtchn = evtchn;
+- irq = bind_interdomain_evtchn_to_irq_lateeoi(dev, evtchn);
++ irq = bind_evtchn_to_irq_lateeoi(evtchn);
+ if (irq < 0)
+ return irq;
+ info->irq = irq;
--- /dev/null
+From 70b70a4307cccebe91388337b1c85735ce4de6ff Mon Sep 17 00:00:00 2001
+From: Lukas Wunner <lukas@wunner.de>
+Date: Mon, 18 Sep 2023 14:48:01 +0200
+Subject: PCI/sysfs: Protect driver's D3cold preference from user space
+
+From: Lukas Wunner <lukas@wunner.de>
+
+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 <lukas@wunner.de>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
+Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
+Cc: stable@vger.kernel.org # v4.8+
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+@@ -910,7 +910,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
+@@ -508,10 +508,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);
+
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
+hvc-xen-fix-event-channel-handling-for-secondary-consoles.patch
+pci-sysfs-protect-driver-s-d3cold-preference-from-user-space.patch
--- /dev/null
+From dd976a97d15b47656991e185a94ef42a0fa5cfd4 Mon Sep 17 00:00:00 2001
+From: Muhammad Usama Anjum <usama.anjum@collabora.com>
+Date: Mon, 9 Oct 2023 21:20:20 +0500
+Subject: tty/sysrq: replace smp_processor_id() with get_cpu()
+
+From: Muhammad Usama Anjum <usama.anjum@collabora.com>
+
+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 <usama.anjum@collabora.com>
+Link: https://lore.kernel.org/r/20231009162021.3607632-1-usama.anjum@collabora.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/sysrq.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/tty/sysrq.c
++++ b/drivers/tty/sysrq.c
+@@ -263,13 +263,14 @@ static void sysrq_handle_showallcpus(int
+ if (in_hardirq())
+ 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();
+ }
+ }
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
