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
--- /dev/null
+From 89bb3dc13ac29a563f4e4c555e422882f64742bd Mon Sep 17 00:00:00 2001
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+Date: Wed, 14 May 2025 16:25:20 +0300
+Subject: usb: Flush altsetting 0 endpoints before reinitializating them after reset.
+
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+
+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 <stable@kernel.org>
+Fixes: 4fe0387afa89 ("USB: don't send Set-Interface after reset")
+Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Link: https://lore.kernel.org/r/20250514132520.225345-1-mathias.nyman@linux.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 {
--- /dev/null
+From 8b68e978718f14fdcb080c2a7791c52a0d09bc6d Mon Sep 17 00:00:00 2001
+From: Thomas Gleixner <tglx@linutronix.de>
+Date: Wed, 26 Feb 2025 16:01:57 +0100
+Subject: x86/iopl: Cure TIF_IO_BITMAP inconsistencies
+
+From: Thomas Gleixner <tglx@linutronix.de>
+
+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 <tglx@linutronix.de>
+Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/87wmdceom2.ffs@tglx
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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.
--- /dev/null
+From 7f9bbc1140ff8796230bc2634055763e271fd692 Mon Sep 17 00:00:00 2001
+From: Stefano Stabellini <stefano.stabellini@amd.com>
+Date: Mon, 12 May 2025 14:54:52 -0700
+Subject: xen/arm: call uaccess_ttbr0_enable for dm_op hypercall
+
+From: Stefano Stabellini <stefano.stabellini@amd.com>
+
+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 <stefano.stabellini@amd.com>
+Reviewed-by: Juergen Gross <jgross@suse.com>
+Message-ID: <alpine.DEB.2.22.394.2505121446370.8380@ubuntu-linux-20-04-desktop>
+Signed-off-by: Juergen Gross <jgross@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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