kernel/git/stable/linux-stable.git/arch, branch linux-5.10.y

x86/pkeys: Fix pkey_alloc() return value when pkeys are not supported

2026-09-14T11:19:14+00:00

[ Upstream commit dee87e09b0dd63da9b1e1876167ccae37842dfd0 ] The man page for pkey_alloc(2) specifies that it should return -1 with the errno set to ENOSPC when pkeys are not supported [1]. However, on x86 pkey_alloc() sets errno to EINVAL when called for the first time on a CPU that does not support pkeys. The root cause of this is the x86 implementation of mm_pkey_alloc() not directly checking if pkeys are supported. It only checks if all the pkeys have been allocated by comparing the allocation map against all_pkeys_mask. When OSPKE is not enabled, init_new_context() skips the initialization of the allocation map, leaving it as 0, while all_pkeys_mask is 1. mm_pkey_alloc() interprets this as there being a pkey available and it returns pkey 0. Then, pkey_alloc() fails with -EINVAL from arch_set_user_pkey_access() instead of returning -ENOSPC. Subsequent calls to pkey_alloc() do return -ENOSPC because pkey 0 is left marked as allocated. Change mm_pkey_alloc() to directly check if OSPKE is enabled, and return -1 if it is not, which causes pkey_alloc() to return -ENOSPC. The arm64 and powerpc implementations of mm_pkey_alloc() already do this check. [1] https://man7.org/linux/man-pages/man2/pkey_alloc.2.html [ dhansen: use arch_pkeys_enabled() to follow arm ] Fixes: e8c24d3a23a4 ("x86/pkeys: Allocation/free syscalls") Signed-off-by: Bijan Tabatabai Signed-off-by: Dave Hansen Link: https://patch.msgid.link/20260716220604.26452-1-bijan311@gmail.com Signed-off-by: Sasha Levin

powerpc/configs: enable CONFIG_RAS to fix EDAC support

2026-09-14T11:19:12+00:00

[ Upstream commit 3921cfc2e8155a767235801be88cbd0e4c73508d ] Before commit e3c4ff6d8c94 ("EDAC: Remove EDAC_MM_EDAC") EDAC_MM_EDAC selected RAS, after that commit, EDAC depends on RAS, but nobody enables it. Enable it in the config again. Fixes: e3c4ff6d8c94 ("EDAC: Remove EDAC_MM_EDAC") Signed-off-by: Michael Walle Acked-by: Borislav Petkov (AMD) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260730105546.3658570-1-mwalle@kernel.org Signed-off-by: Sasha Levin

m68k: Fix backtraces for non-running tasks

2026-09-14T11:19:12+00:00

[ Upstream commit 09f71dbeb287e367beea56d9ac8a3d356ef5e02a ] When no stack pointer is supplied, show_stack() starts at thread.esp0. This is the saved userspace register frame, not where a task was switched out. For kernel threads it points to the zeroed frame created by copy_thread(), so sched_show_task() prints no useful backtrace. Use thread.ksp for non-current tasks. It is saved by switch_to() and is already used by __get_wchan(). For current, start at the current stack frame, as is already done when no task is supplied. Tested on qemu-system-m68k -M virt using SysRq-t. All task dumps contained resolved frames. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Karl Mehltretter Reviewed-by: Geert Uytterhoeven Tested-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260723041055.47289-1-kmehltretter@gmail.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin

ARM: dts: helios4: add SATA regulator supplies

2026-09-14T11:19:11+00:00

[ Upstream commit 7a90520e8c9a8f48fe6f3e741cf34d8c2b6dbc61 ] The ahci-mvebu driver and libahci_platform request three supplies on SATA controller and port nodes: - ahci-supply (controller power) - phy-supply (PHY power) - target-supply (disk power per port) Without them the regulator core prints notices at boot, e.g.: supply ahci not found, using dummy regulator supply phy not found, using dummy regulator supply target not found, using dummy regulator The SATA controller and PHY inside the Armada 388 SoC are powered by the 3.3V I/O rail; the four disk bays are powered by the 5V HDD rail. Wire the existing fixed regulators accordingly. Fixes: ced8025b569e ("ARM: dts: armada388-helios4") Assisted-by: opencode:big-pickle Signed-off-by: Rosen Penev Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin

ARM: dts: helios4: add vcc-supply to GPIO expander

2026-09-14T11:19:11+00:00

[ Upstream commit c23988f84496e937dd255564cb30bec67608dcc6 ] The pca953x driver requests a 'vcc' supply, producing: pca953x 0-0020: supply vcc not found, using dummy regulator The PCA9655 (PCA9555-compatible) expander is powered by the same always-on 3.3V rail as the other I2C devices on the bus. Add vcc-supply = <®_3p3v> to silence the warning. Fixes: ced8025b569e ("ARM: dts: armada388-helios4") Assisted-by: opencode:big-pickle Signed-off-by: Rosen Penev Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin

ARM: dts: helios4: add vcc-supply to EEPROM

2026-09-14T11:19:11+00:00

[ Upstream commit ef65cf08bd1aa723de2854d02fb8eb8cca273c90 ] The at24 driver requests a 'vcc' supply for the EEPROM, producing 'supply vcc not found, using dummy regulator' at boot when the property is missing. The EEPROM sits on the Helios 4 and is powered by the same always-on 3.3V rail used by other on-board I2C devices. Add vcc-supply = <®_3p3v> to silence the warning. Fixes: ced8025b569e ("ARM: dts: armada388-helios4") Assisted-by: opencode:big-pickle Signed-off-by: Rosen Penev Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin

arm64: dts: turris-mox: fix usb3 phys

2026-09-14T11:19:11+00:00

[ Upstream commit 0c2a8eed95160e41b367a1fa605a2c1b24a9639a ] After commit 00e6d608fe80b0f6 ("arm64: dts: marvell: armada-37xx: swap PHYs' order in USB3 controller node") swapped USB3 PHY order, USB initialization breaks on Turris MOX. This regression was exposed by commit 91ddf6f722084383 ("phy: marvell: mvebu-a3700-utmi: fix incorrect USB2_PHY_CTRL register access") which made USB2 devices not work at all. Fix the issue by explicitly adding all USB3 PHYs and PHY names to Turris MOX device-tree. Fixes: 7109d817db2e ("arm64: dts: marvell: add DTS for Turris Mox") Signed-off-by: Tomáš Macholda Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin

arm64: hibernate: Restore DAIF state on error

2026-09-14T11:19:10+00:00

[ Upstream commit 541549827889d0380fd73f8aacb5de6ef7a5a1ac ] Sashiko AI has reported that if swsusp_mte_save_tags() for some reason fails we return from swsusp_arch_suspend() with DAIF being masked - that is not what we'd expect. Restore the saved DAIF state before returning from the error path. Fixes: ee11f332af96 ("arm64: mte: Save tags when hibernating") Signed-off-by: Vladimir Murzin Reviewed-by: Jinjie Ruan Signed-off-by: Will Deacon Signed-off-by: Sasha Levin

arm64: hibernate: mask DAIF before restoring hibernated kernel

2026-09-14T11:19:10+00:00

[ Upstream commit 684bde100117931f4c51c644a95f42f2dab041bc ] The arm64 hibernate code manages the exception masking in an unsound way, leading to potential crashes and/or warnings during resume. When a hibernation image is saved in `swsusp_arch_suspend()`, all DAIF exceptions are masked (by virtue of `local_daif_save()`), and the suspended image is saved assuming that all DAIF exceptions will remain masked when the image is restored. When a hibernation image is resumed by `swsusp_arch_resume()`, only interrupts are masked (by virtue of `local_irq_disable()` in `resume_target_kernel()`). When pseudo-NMI is enabled the DAIF.IF bits will be clear, and regardless of pseudo-NMI the DAIF.DA bits will be clear. This means that there are two problems: (1) It is possible to take Debug, SError, or pseudo-NMI exceptions during the resume process. This is unsafe, as during the resume process both the old ane new kernels will tranisently be in an inconsistent state, and swsusp_arch_suspend_exit() won't retain an executable mapping of any exception vectors. Any exception taken here will be fatal and silent. (2) When re-entering the resumed kernel, some DAIF bits will be clear unexpectedly. This permits Debug, SError, or pseudo-NMI exceptions to be taken for a short period while the resumed kernel is not yet in a consistent state. This is detected by CONFIG_ARM64_DEBUG_PRIORITY_MASKING. Avoid these issues by masking all DAIF exceptions during resume. Fixes: 82869ac57b5d ("arm64: kernel: Add support for hibernate/suspend-to-disk") Signed-off-by: Ada Couprie Diaz Signed-off-by: Vladimir Murzin Reviewed-by: Jinjie Ruan Signed-off-by: Will Deacon Signed-off-by: Sasha Levin

ARM: 9485/1: mm: acquire mmap write lock around show_pte() for user faults

2026-09-14T11:19:09+00:00

[ Upstream commit 1039bffd6ae9c75b42b7d148d6c1106134107b66 ] When CONFIG_DEBUG_USER=y, and cmdline "user_debug=31" is set, a user fault may trigger show_pte() without any lock. If another thread in the same process concurrently calls munmap(), the page table pages may be freed while show_pte() is still traversing them, causing a use-after-free in show_pte(). If CONFIG_ARM_LPAE=y, this may cause a kernel panic if the pages table of PMD are freed when show_pte() is running. Acquire mmap_write_lock() around show_pte() for user faults to fix the contention. For user faults, additionally restrict that show_pte() is called only when the addr is a user-space address (addr < TASK_SIZE). This is because the lock of tsk->mm only protects the virtual memory of user address space, furthermore, dumping the page tables of a kernel-space address for user faults is unnecessary and may have security implications. Keep everything unchanged for kernel faults, because the kernel is already in the "oops" state, acquiring a lock may risk a deadlock. Co-developed-by: Qi Xi Fixes: 6d021b724481 ("ARM: dump pgd, pmd and pte states on unhandled data abort faults") Link: https://lore.kernel.org/20260716014022.2823-1-xieyuanbin1@huawei.com Acked-by: Lorenzo Stoakes (ARM) Reviewed-by: Linus Walleij Signed-off-by: Qi Xi Signed-off-by: Xie Yuanbin Signed-off-by: Russell King Signed-off-by: Sasha Levin