From: Greg Kroah-Hartman Date: Tue, 17 Jun 2025 14:30:44 +0000 (+0200) Subject: 5.10-stable patches X-Git-Tag: v6.6.94~26 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=090196675199aff04348a6da7895598358169abc;p=thirdparty%2Fkernel%2Fstable-queue.git 5.10-stable patches added patches: usb-flush-altsetting-0-endpoints-before-reinitializating-them-after-reset.patch x86-iopl-cure-tif_io_bitmap-inconsistencies.patch xen-arm-call-uaccess_ttbr0_enable-for-dm_op-hypercall.patch --- diff --git a/queue-5.10/series b/queue-5.10/series index 40fc259275..341659055d 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -149,3 +149,6 @@ kbuild-add-clang_flags-to-as-instr.patch kbuild-add-clang_flags-to-kbuild_cppflags.patch kbuild-add-kbuild_cppflags-to-as-option-invocation.patch drm-amd-display-do-not-add-mhard-float-to-dcn2-1-0-_resource.o-for-clang.patch +usb-flush-altsetting-0-endpoints-before-reinitializating-them-after-reset.patch +xen-arm-call-uaccess_ttbr0_enable-for-dm_op-hypercall.patch +x86-iopl-cure-tif_io_bitmap-inconsistencies.patch diff --git a/queue-5.10/usb-flush-altsetting-0-endpoints-before-reinitializating-them-after-reset.patch b/queue-5.10/usb-flush-altsetting-0-endpoints-before-reinitializating-them-after-reset.patch new file mode 100644 index 0000000000..4635777a67 --- /dev/null +++ b/queue-5.10/usb-flush-altsetting-0-endpoints-before-reinitializating-them-after-reset.patch @@ -0,0 +1,75 @@ +From 89bb3dc13ac29a563f4e4c555e422882f64742bd Mon Sep 17 00:00:00 2001 +From: Mathias Nyman +Date: Wed, 14 May 2025 16:25:20 +0300 +Subject: usb: Flush altsetting 0 endpoints before reinitializating them after reset. + +From: Mathias Nyman + +commit 89bb3dc13ac29a563f4e4c555e422882f64742bd upstream. + +usb core avoids sending a Set-Interface altsetting 0 request after device +reset, and instead relies on calling usb_disable_interface() and +usb_enable_interface() to flush and reset host-side of those endpoints. + +xHCI hosts allocate and set up endpoint ring buffers and host_ep->hcpriv +during usb_hcd_alloc_bandwidth() callback, which in this case is called +before flushing the endpoint in usb_disable_interface(). + +Call usb_disable_interface() before usb_hcd_alloc_bandwidth() to ensure +URBs are flushed before new ring buffers for the endpoints are allocated. + +Otherwise host driver will attempt to find and remove old stale URBs +from a freshly allocated new ringbuffer. + +Cc: stable +Fixes: 4fe0387afa89 ("USB: don't send Set-Interface after reset") +Signed-off-by: Mathias Nyman +Link: https://lore.kernel.org/r/20250514132520.225345-1-mathias.nyman@linux.intel.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/core/hub.c | 16 ++++++++++++++-- + 1 file changed, 14 insertions(+), 2 deletions(-) + +--- a/drivers/usb/core/hub.c ++++ b/drivers/usb/core/hub.c +@@ -6014,6 +6014,7 @@ static int usb_reset_and_verify_device(s + struct usb_hub *parent_hub; + struct usb_hcd *hcd = bus_to_hcd(udev->bus); + struct usb_device_descriptor descriptor; ++ struct usb_interface *intf; + struct usb_host_bos *bos; + int i, j, ret = 0; + int port1 = udev->portnum; +@@ -6074,6 +6075,18 @@ static int usb_reset_and_verify_device(s + if (!udev->actconfig) + goto done; + ++ /* ++ * Some devices can't handle setting default altsetting 0 with a ++ * Set-Interface request. Disable host-side endpoints of those ++ * interfaces here. Enable and reset them back after host has set ++ * its internal endpoint structures during usb_hcd_alloc_bandwith() ++ */ ++ for (i = 0; i < udev->actconfig->desc.bNumInterfaces; i++) { ++ intf = udev->actconfig->interface[i]; ++ if (intf->cur_altsetting->desc.bAlternateSetting == 0) ++ usb_disable_interface(udev, intf, true); ++ } ++ + mutex_lock(hcd->bandwidth_mutex); + ret = usb_hcd_alloc_bandwidth(udev, udev->actconfig, NULL, NULL); + if (ret < 0) { +@@ -6105,12 +6118,11 @@ static int usb_reset_and_verify_device(s + */ + for (i = 0; i < udev->actconfig->desc.bNumInterfaces; i++) { + struct usb_host_config *config = udev->actconfig; +- struct usb_interface *intf = config->interface[i]; + struct usb_interface_descriptor *desc; + ++ intf = config->interface[i]; + desc = &intf->cur_altsetting->desc; + if (desc->bAlternateSetting == 0) { +- usb_disable_interface(udev, intf, true); + usb_enable_interface(udev, intf, true); + ret = 0; + } else { diff --git a/queue-5.10/x86-iopl-cure-tif_io_bitmap-inconsistencies.patch b/queue-5.10/x86-iopl-cure-tif_io_bitmap-inconsistencies.patch new file mode 100644 index 0000000000..5e2d15b46b --- /dev/null +++ b/queue-5.10/x86-iopl-cure-tif_io_bitmap-inconsistencies.patch @@ -0,0 +1,118 @@ +From 8b68e978718f14fdcb080c2a7791c52a0d09bc6d Mon Sep 17 00:00:00 2001 +From: Thomas Gleixner +Date: Wed, 26 Feb 2025 16:01:57 +0100 +Subject: x86/iopl: Cure TIF_IO_BITMAP inconsistencies + +From: Thomas Gleixner + +commit 8b68e978718f14fdcb080c2a7791c52a0d09bc6d upstream. + +io_bitmap_exit() is invoked from exit_thread() when a task exists or +when a fork fails. In the latter case the exit_thread() cleans up +resources which were allocated during fork(). + +io_bitmap_exit() invokes task_update_io_bitmap(), which in turn ends up +in tss_update_io_bitmap(). tss_update_io_bitmap() operates on the +current task. If current has TIF_IO_BITMAP set, but no bitmap installed, +tss_update_io_bitmap() crashes with a NULL pointer dereference. + +There are two issues, which lead to that problem: + + 1) io_bitmap_exit() should not invoke task_update_io_bitmap() when + the task, which is cleaned up, is not the current task. That's a + clear indicator for a cleanup after a failed fork(). + + 2) A task should not have TIF_IO_BITMAP set and neither a bitmap + installed nor IOPL emulation level 3 activated. + + This happens when a kernel thread is created in the context of + a user space thread, which has TIF_IO_BITMAP set as the thread + flags are copied and the IO bitmap pointer is cleared. + + Other than in the failed fork() case this has no impact because + kernel threads including IO workers never return to user space and + therefore never invoke tss_update_io_bitmap(). + +Cure this by adding the missing cleanups and checks: + + 1) Prevent io_bitmap_exit() to invoke task_update_io_bitmap() if + the to be cleaned up task is not the current task. + + 2) Clear TIF_IO_BITMAP in copy_thread() unconditionally. For user + space forks it is set later, when the IO bitmap is inherited in + io_bitmap_share(). + +For paranoia sake, add a warning into tss_update_io_bitmap() to catch +the case, when that code is invoked with inconsistent state. + +Fixes: ea5f1cd7ab49 ("x86/ioperm: Remove bitmap if all permissions dropped") +Reported-by: syzbot+e2b1803445d236442e54@syzkaller.appspotmail.com +Signed-off-by: Thomas Gleixner +Signed-off-by: Borislav Petkov (AMD) +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/87wmdceom2.ffs@tglx +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kernel/ioport.c | 13 +++++++++---- + arch/x86/kernel/process.c | 6 ++++++ + 2 files changed, 15 insertions(+), 4 deletions(-) + +--- a/arch/x86/kernel/ioport.c ++++ b/arch/x86/kernel/ioport.c +@@ -33,8 +33,9 @@ void io_bitmap_share(struct task_struct + set_tsk_thread_flag(tsk, TIF_IO_BITMAP); + } + +-static void task_update_io_bitmap(struct task_struct *tsk) ++static void task_update_io_bitmap(void) + { ++ struct task_struct *tsk = current; + struct thread_struct *t = &tsk->thread; + + if (t->iopl_emul == 3 || t->io_bitmap) { +@@ -54,7 +55,12 @@ void io_bitmap_exit(struct task_struct * + struct io_bitmap *iobm = tsk->thread.io_bitmap; + + tsk->thread.io_bitmap = NULL; +- task_update_io_bitmap(tsk); ++ /* ++ * Don't touch the TSS when invoked on a failed fork(). TSS ++ * reflects the state of @current and not the state of @tsk. ++ */ ++ if (tsk == current) ++ task_update_io_bitmap(); + if (iobm && refcount_dec_and_test(&iobm->refcnt)) + kfree(iobm); + } +@@ -192,8 +198,7 @@ SYSCALL_DEFINE1(iopl, unsigned int, leve + } + + t->iopl_emul = level; +- task_update_io_bitmap(current); +- ++ task_update_io_bitmap(); + return 0; + } + +--- a/arch/x86/kernel/process.c ++++ b/arch/x86/kernel/process.c +@@ -143,6 +143,7 @@ int copy_thread(unsigned long clone_flag + frame->ret_addr = (unsigned long) ret_from_fork; + p->thread.sp = (unsigned long) fork_frame; + p->thread.io_bitmap = NULL; ++ clear_tsk_thread_flag(p, TIF_IO_BITMAP); + p->thread.iopl_warn = 0; + memset(p->thread.ptrace_bps, 0, sizeof(p->thread.ptrace_bps)); + +@@ -401,6 +402,11 @@ void native_tss_update_io_bitmap(void) + } else { + struct io_bitmap *iobm = t->io_bitmap; + ++ if (WARN_ON_ONCE(!iobm)) { ++ clear_thread_flag(TIF_IO_BITMAP); ++ native_tss_invalidate_io_bitmap(); ++ } ++ + /* + * Only copy bitmap data when the sequence number differs. The + * update time is accounted to the incoming task. diff --git a/queue-5.10/xen-arm-call-uaccess_ttbr0_enable-for-dm_op-hypercall.patch b/queue-5.10/xen-arm-call-uaccess_ttbr0_enable-for-dm_op-hypercall.patch new file mode 100644 index 0000000000..0eb582cf4d --- /dev/null +++ b/queue-5.10/xen-arm-call-uaccess_ttbr0_enable-for-dm_op-hypercall.patch @@ -0,0 +1,63 @@ +From 7f9bbc1140ff8796230bc2634055763e271fd692 Mon Sep 17 00:00:00 2001 +From: Stefano Stabellini +Date: Mon, 12 May 2025 14:54:52 -0700 +Subject: xen/arm: call uaccess_ttbr0_enable for dm_op hypercall + +From: Stefano Stabellini + +commit 7f9bbc1140ff8796230bc2634055763e271fd692 upstream. + +dm_op hypercalls might come from userspace and pass memory addresses as +parameters. The memory addresses typically correspond to buffers +allocated in userspace to hold extra hypercall parameters. + +On ARM, when CONFIG_ARM64_SW_TTBR0_PAN is enabled, they might not be +accessible by Xen, as a result ioreq hypercalls might fail. See the +existing comment in arch/arm64/xen/hypercall.S regarding privcmd_call +for reference. + +For privcmd_call, Linux calls uaccess_ttbr0_enable before issuing the +hypercall thanks to commit 9cf09d68b89a. We need to do the same for +dm_op. This resolves the problem. + +Cc: stable@kernel.org +Fixes: 9cf09d68b89a ("arm64: xen: Enable user access before a privcmd hvc call") +Signed-off-by: Stefano Stabellini +Reviewed-by: Juergen Gross +Message-ID: +Signed-off-by: Juergen Gross +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/xen/hypercall.S | 21 ++++++++++++++++++++- + 1 file changed, 20 insertions(+), 1 deletion(-) + +--- a/arch/arm64/xen/hypercall.S ++++ b/arch/arm64/xen/hypercall.S +@@ -84,7 +84,26 @@ HYPERCALL1(tmem_op); + HYPERCALL1(platform_op_raw); + HYPERCALL2(multicall); + HYPERCALL2(vm_assist); +-HYPERCALL3(dm_op); ++ ++SYM_FUNC_START(HYPERVISOR_dm_op) ++ mov x16, #__HYPERVISOR_dm_op; \ ++ /* ++ * dm_op hypercalls are issued by the userspace. The kernel needs to ++ * enable access to TTBR0_EL1 as the hypervisor would issue stage 1 ++ * translations to user memory via AT instructions. Since AT ++ * instructions are not affected by the PAN bit (ARMv8.1), we only ++ * need the explicit uaccess_enable/disable if the TTBR0 PAN emulation ++ * is enabled (it implies that hardware UAO and PAN disabled). ++ */ ++ uaccess_ttbr0_enable x6, x7, x8 ++ hvc XEN_IMM ++ ++ /* ++ * Disable userspace access from kernel once the hyp call completed. ++ */ ++ uaccess_ttbr0_disable x6, x7 ++ ret ++SYM_FUNC_END(HYPERVISOR_dm_op); + + SYM_FUNC_START(privcmd_call) + mov x16, x0