kernel/linux.git/arch, branch v5.10.261

perf/x86/amd/core: Always use the NMI latency mitigation

2026-07-24T13:49:24+00:00

commit 73a4c02f94a98d94480c3e5c81450215a4da05ba upstream. Commit df4d29732fda ("perf/x86/amd: Change/fix NMI latency mitigation to use a timestamp") fixed handling of late-arriving NMIs but limited the mitigation to processors having X86_FEATURE_PERFCTR_CORE. However, it is unclear if processors without this feature are also affected. When Mediated vPMU is enabled on affected hardware, it is also possible to bypass the fix inside KVM guests if X86_FEATURE_PERFCTR_CORE is removed from the guest CPUID (e.g. using "-cpu host,-perfctr-core" with QEMU). Hence, use the mitigation at all times. Fixes: df4d29732fda ("perf/x86/amd: Change/fix NMI latency mitigation to use a timestamp") Signed-off-by: Sandipan Das Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/29a3c970da289ab8f24282933bdb36545c0403e8.1780325517.git.sandipan.das@amd.com Signed-off-by: Greg Kroah-Hartman

KVM: Move kvm_io_bus_get_dev() locking responsibilities to callers

2026-07-24T13:49:23+00:00

commit 3a07249981629ace483ebbef81ef6b34c2d2afec upstream. kvm_io_bus_get_dev() returns a device that is only matched by the address, and nothing else. This can cause a lifetime issue if the matched device is not the expected type, as by the time the caller can introspect the object, it might be gone (the srcu lock having been dropped). Given that there is only a single user of this helper, the simplest option is to move the locking responsibility to the caller, which can keep the srcu lock held for as long as it wants. Note that this aligns with other kvm_io_bus*() helpers, which already require the srcu lock to be held by the callers. Reported-by: Will Deacon Fixes: 8a39d00670f07 ("KVM: kvm_io_bus: Add kvm_io_bus_get_dev() call") Link: https://lore.kernel.org/all/20260626111344.802555-1-maz@kernel.org Cc: stable@vger.kernel.org Reviewed-by: Oliver Upton Link: https://patch.msgid.link/20260627105105.1005990-1-maz@kernel.org Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman

gpio: pca953x: Make platform teardown callback return void

2026-07-24T13:49:22+00:00

[ Upstream commit 6a8f359c3132e4f51bdb263ad74ec632c65e55fd ] All platforms that provide a teardown callback return 0. New users are supposed to not make use of platform support, so there is no functionality lost. This patch is a preparation for making i2c remove callbacks return void. Reviewed-by: Andy Shevchenko Signed-off-by: Uwe Kleine-König Acked-by: Bartosz Golaszewski Signed-off-by: Wolfram Sang Stable-dep-of: 1f0bdc2884b6 ("usb: typec: ucsi: ccg: Fix use-after-free of ucsi on remove") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

powerpc/spufs: fix out-of-bounds access in spufs_mem_mmap_access()

2026-07-24T13:49:16+00:00

commit 47b87f469a35b5ffc81c16eee6b13a9b6c8d55c6 upstream. spufs_mem_mmap_access() computes the local store offset as address - vma->vm_start, but bounds-checks it against vma->vm_end instead of the local store size. On 64-bit, offset is always well below vma->vm_end, so the clamp never fires and len stays unbounded against the LS_SIZE buffer returned by ctx->ops->get_ls(). Reject offsets at or beyond LS_SIZE and clamp len to the remaining space, mirroring the guard already used by spufs_mem_mmap_fault() and spufs_ps_fault(). Fixes: a352894d0705 ("spufs: use new vm_ops->access to allow local state access from gdb") Reported-by: Yuhao Jiang Cc: stable@vger.kernel.org Signed-off-by: Junrui Luo Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/SYBPR01MB7881EE775E8B51C09F5A29E7AF152@SYBPR01MB7881.ausprd01.prod.outlook.com Signed-off-by: Greg Kroah-Hartman

MIPS: DEC: Ensure 32-bit stack location for o32 prom_printf()

2026-07-24T13:49:11+00:00

commit 5ff79e8bdc75db51e30298a75939e2308e7658e0 upstream. In 64-bit configurations calling any firmware entry points from a kernel thread other than the initial one will result in a situation where the stack has been placed in the XKPHYS 64-bit memory segment. Consequently the stack pointer is no longer a 32-bit value and when the 32-bit firmware code called uses 32-bit ALU operations to manipulate the stack pointer, the calculated result is incorrect (in fact in the 64-bit MIPS ISA almost all 32-bit ALU operations will produce an unpredictable result when executed on 64-bit data) and control goes astray. This may happen when no final console driver has been enabled in the configuration and consequently the initial console continues being used late into bootstrap, or with an upcoming change that will switch the zs driver to use a platform device, which in turn will make the console handover happen only after other kernel threads have already been started, and the kernel will hang at: pid_max: default: 32768 minimum: 301 or somewhat later, but always before: cblist_init_generic: Setting adjustable number of callback queues. has been printed. It seems that only the prom_printf() entry point is affected. Of all the other entry points wired only rex_slot_address() and rex_gettcinfo() are called from a kernel thread other than the initial one, specifically kernel_init(), and they are leaf functions that do no business with the stack, having worked with no issue ever since 64-bit support was added for the platform back in 2002. To address this issue then, arrange for the stack to be switched in the o32 wrapper as required for prom_printf() only, by supplying call_o32() with a pointer to a chunk of initdata space, which is placed in the CKSEG0 32-bit compatibility segment, observing that prom_printf() is only called from console output handler and therefore with the console lock held, implying no need for this code to be reentrant. Other firmware entry points may be called with interrupts enabled and no lock held, and may therefore require that call_o32() be reentrant. They trigger no issue at this point and "if it ain't broke, don't fix it," so just leave them alone. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Maciej W. Rozycki Cc: stable@vger.kernel.org # v2.6.12+ Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman

MIPS: ip22-gio: fix device reference leak in probe

2026-07-24T13:49:11+00:00

commit b82930a4c5dbc5c4df39c0f93d968c239f2c6885 upstream. The gio probe function needlessly takes a device reference which is never released and therefore prevents unbound gio devices from being freed. Fixes: e84de0c61905 ("MIPS: GIO bus support for SGI IP22/28") Cc: stable@vger.kernel.org # 3.3 Cc: Thomas Bogendoerfer Signed-off-by: Johan Hovold Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman

MIPS: ip22-gio: fix kfree() of static object

2026-07-24T13:49:11+00:00

commit c62cdd3e919bdf84c37ec46810f87cdb1736e822 upstream. The gio bus root device is a statically allocated object which must not be freed by kfree() on failure to register the device or bus. Fixes: 82242d28ff8b ("MIPS: IP22: Add missing put_device call") Cc: stable@vger.kernel.org # 3.17 Cc: Levente Kurusa Signed-off-by: Johan Hovold Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman

MIPS: ip22-gio: fix gio device memory leak

2026-07-24T13:49:11+00:00

commit 7de9a1b45f5a95b58145653c525c8fb80292d9ab upstream. The gio device release callback was never wired up so gio devices are not freed when the last reference is dropped. Fixes: e84de0c61905 ("MIPS: GIO bus support for SGI IP22/28") Cc: stable@vger.kernel.org # 3.3 Cc: Thomas Bogendoerfer Signed-off-by: Johan Hovold Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman

x86/boot: Reject too long acpi_rsdp= values

2026-07-24T13:49:10+00:00

commit d130041a7b96f79cd4c7079a6c2431a6db4c9619 upstream. cmdline_find_option() returns the full length of the parsed acpi_rsdp= value. get_cmdline_acpi_rsdp() then silently truncates values which do not fit in the val[] buffer. Prevent boot_kstrtoul() from parsing a truncated value and then the kernel from silently using the wrong RSDP address, see discussion in Link:. Issue a warning so that the user is aware that s/he supplied a malformed value and can get feedback instead of silent crashes. [ bp: Make commit message more precise. ] Fixes: 3c98e71b42a7 ("x86/boot: Add "acpi_rsdp=" early parsing") Signed-off-by: Thorsten Blum Signed-off-by: Borislav Petkov (AMD) Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/20260617130417.36651-4-thorsten.blum@linux.dev Signed-off-by: Greg Kroah-Hartman

x86/boot: Validate console=uart8250 baud rate to fix early boot hang

2026-07-24T13:49:10+00:00

commit ffa0aa5b625fe0bed7463ac613f8b06676ff4542 upstream. When the baud rate is empty, 0, invalid, or overflows to 0 when stored as an int, the system will hang during early boot because of a division by zero in early_serial_init(). Fall back to DEFAULT_BAUD when the resulting baud rate is 0 to prevent an early system hang. Fixes: ce0aa5dd20e4 ("x86, setup: Make the setup code also accept console=uart8250") Signed-off-by: Thorsten Blum Signed-off-by: Ingo Molnar Cc: "H. Peter Anvin" Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260713194924.126472-3-thorsten.blum@linux.dev Signed-off-by: Greg Kroah-Hartman