kernel/git/stable/linux-stable.git/arch/arm64, branch linux-rolling-stable

arm64: process: Fix context switching MTE store-only tag check

2026-09-14T11:41:04+00:00

[ Upstream commit b8f070ac3167595069feb1f794c127b805115645 ] SCTLR_EL1.TCSO0 is set when user opt-in for MTE store-only tag check mode. However, it is not part of SCTLR_USER_MASK which imply that on context switch we never clear SCTLR_EL1.TCSO0, so we are leaking that setting into another task. Fix that by including SCTLR_EL1_TCSO0_MASK into SCTLR_USER_MASK Fixes: 4d51ff5bba00 ("arm64/kernel: Support store-only mte tag check") Signed-off-by: Vladimir Murzin Reviewed-by: Catalin Marinas Reviewed-by: Yeoreum Yun Signed-off-by: Will Deacon Signed-off-by: Sasha Levin

arm64: ptdump: Make note_page_flush() range aware

2026-09-14T11:41:03+00:00

[ Upstream commit 902caade3cfd60f99bf71b355e7c86344bd831e5 ] note_page_flush() calls note_page() with addr == 0 and level == -1 to dump the last row of a ptdump. addr == 0 (1 << 64 wrapped around) renders a huge region with enormous size for address spaces with IA bits < 64. For example the stage-2 page tables and the EFI runtime page table. More importantly, the last region of the address space and everything after the address space up to 1 << 64 are merged into one row of output. If the last region within the address space is valid, it will appear to remain valid up to 1 << 64 with the same attributes. Currently only the EFI runtime ptdump is affected by this, but KVM will soon fix its stage-2 ptdump by using note_page_flush(). Here is an example of an EFI runtime ptdump (last row): 0x0000008000000000-0x0000000000000000 17179868672G PGD With this patch: 0x0000008000000000-0x0001000000000000 261632G PGD To fix this, cache the end address of a ptdump in ptdump_pg_state so note_page_flush() can call the final note_page() with the correct end address. Fixes: 9d80448ac92b ("efi/arm64: Add debugfs node to dump UEFI runtime page tables") Signed-off-by: Wei-Lin Chang Reviewed-by: Marc Zyngier Signed-off-by: Will Deacon Signed-off-by: Sasha Levin

bpf, arm64: Fix stack-passed arguments for indirect trampolines

2026-09-14T11:40:46+00:00

[ Upstream commit 50de1c47a41d4031f6002969e71dc6954dedb6b2 ] save_args() reads stack-passed arguments relative to FP assuming the trampoline is entered through the fentry call from a traced function, in which case both the parent frame (FP/x9) and the traced function frame (FP/LR) are saved before FP is set, so the arguments start at FP + 32. An indirect trampoline for a struct_ops callback is entered through a function pointer (blr), so only the FP/LR frame is pushed and the arguments start at FP + 16, not FP + 32. Every stack-passed argument of a struct_ops callback with more than eight argument slots is read two slots off. This went unnoticed because no struct_ops member passed arguments on the stack until bpf_testmod_ops3::test_arena_stack, added by commit 2d4de9a493a0 ("selftests/bpf: Test stack-passed struct_ops arena arguments"). That member covers this on arm64 once the JIT gains arena argument support later in this series. Pass is_struct_ops into save_args() and pick the offset accordingly, mirroring the x86 fix. Fixes: 9014cf56f13d ("bpf, arm64: Support up to 12 function arguments") Signed-off-by: Puranjay Mohan Reviewed-by: Xu Kuohai Link: https://lore.kernel.org/bpf/20260813190356.335181-2-puranjay@kernel.org Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin

bpf, arm64: Clear fetch destination on faulting arena atomic

2026-09-14T11:40:43+00:00

[ Upstream commit ea3f20cb5918fea8e3786899b78fc7bb867c6a5e ] Same problem as on x86-64: add_exception_handler() folds "there is no destination register to clear" and "this is a store" into one DONT_CLEAR value ... if (BPF_CLASS(insn->code) != BPF_LDX && !bpf_atomic_is_load_acq(insn)) dst_reg = DONT_CLEAR; ... which ex_handler_bpf() then reads back as the access direction: bool is_write = (dst_reg == DONT_CLEAR); A RMW carrying BPF_FETCH is both. emit_lse_atomic() reads the old value into src_reg for BPF_{ADD,AND,OR,XOR} | BPF_FETCH and BPF_XCHG, and into r0 for BPF_CMPXCHG, so a fault over an unmapped arena page is correctly reported as a WRITE but leaves that register holding a stale value instead of the 0 that every other BPF_PROBE_* access delivers. Same as on x86-64, add a separate ARENA_WRITE bit for the direction. FIXUP_REG is now filled in by the callers of add_exception_handler(), the BPF_PROBE_ATOMIC one deriving it from bpf_atomic_load_reg(), so that the helper only has to determine the direction. This is how the riscv64 JIT already does it, and it stops the two store callers from handing in a dst_reg that was only going to be overwritten with DONT_CLEAR anyway. Fixes: e612b5c1d3ee ("bpf, arm64: Add support for lse atomics in bpf_arena") Signed-off-by: Daniel Borkmann Reviewed-by: Puranjay Mohan Link: https://patch.msgid.link/20260811131600.506721-4-daniel@iogearbox.net Signed-off-by: Eduard Zingerman Signed-off-by: Sasha Levin

arm64/efi: Avoid voluntary preemption with efi_mm installed

2026-09-14T11:40:42+00:00

[ Upstream commit e98a9d0146372b046d863164025a66ab4488b972 ] Gus reports a bad kernel memory access when using software PAN (CONFIG_ARM64_SW_TTBR0_PAN=y) on a machine with support for EFI runtime services: Unable to handle kernel access to user memory outside uaccess routines at virtual address 00000000f322ff30 Mem abort info: ESR = 0x0000000096000004 FSC = 0x04: level 0 translation fault Internal error: Oops: 0000000096000004 [#1] SMP Workqueue: efi_rts_wq efi_call_rts pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : efi_call_rts+0xd8/0x288 Call trace: efi_call_rts+0xd8/0x288 (P) process_one_work+0x178/0x4f8 worker_thread+0x194/0x328 This is because the fpsimd context management code called from __efi_fpsimd_begin() can preempt voluntarily, returning later to the EFI code with an incorrect value for TTBR0_EL1 thanks to the deferred mm switching used by the software PAN implementation. Since EFI runtime services cannot preempt voluntarily and because the fpsimd switching code does not rely on the TTBR0_EL1 mappings, simply reorder the fpsimd switch so that it occurs before we change the page-table. Cc: Ard Biesheuvel Reported-by: Gus Bourg Tested-by: Gus Bourg Fixes: a5baf582f4c0 ("arm64/efi: Call EFI runtime services without disabling preemption") Link: https://lore.kernel.org/all/20260806000144.3388823-1-gus@bourg.net/ Reviewed-by: Ard Biesheuvel Signed-off-by: Will Deacon Signed-off-by: Sasha Levin

arm64: bti: Disable in-kernel BTI with recent versions of Clang

2026-09-14T11:40:38+00:00

[ Upstream commit d3359af21fc9e7a47577ff90e821b6510ec34dee ] The following BTI exception was seen when loading a livepatch module: Internal error: Oops - BTI: 0000000036000001 [#1] SMP pstate: 634004c9 (nZCv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=jc) pc : kill_orphaned_pgrp+0x0/0x150 lr : do_exit+0x498/0xaf0 [livepatch_combined] The problem is that the patch module's do_exit() is branching to a static function in vmlinux using a module PLT veneer (indirect branch), but the target function doesn't have a BTI landing pad. Clang 21+ omits the landing pad for static functions which can only be reached by a direct branch. That's normally fine for ordinary modules which only branch to global exported functions, but Mark Brown points out [1] that this isn't guaranteed if the module branches between sections. Futhermore, livepatch modules use klp relocations to reference arbitrary kernel symbols, so with CONFIG_RANDOMIZE_MODULE_REGION_FULL the module is far enough from the kernel that every R_AARCH64_CALL26 needs a PLT. Put Clang 21+ in the naughty corner alongside GCC, which suffers from the same issue, by disabling CONFIG_ARM64_BTI_KERNEL until we have a version of the toolchain with the problem resolved. Cc: Ard Biesheuvel Link: https://lore.kernel.org/r/da06bbd3-d04b-4d0f-b331-f5b91bc373a5@sirena.org.uk [1] Fixes: fd1e0fd71f65 ("arm64: Implement HAVE_LIVEPATCH") Signed-off-by: Josh Poimboeuf [will: Stitched together commit message, diff and bug number] Signed-off-by: Will Deacon Signed-off-by: Sasha Levin

arm64: entry: Avoid unnecessary local_irq_disable() on kernel exit

2026-09-14T11:40:38+00:00

[ Upstream commit 39aebe0e89469c2904e60b1e977e0d4dbf33326b ] Currently, when exiting to kernel mode, we attempt involuntary preemption. The preemption logic expects IRQs to be disabled, which is why we call local_irq_disable() before attempting preemption. However, depending on the context, local_irq_disable() may be unnecessary: - __el1_irq(), the non-NMI EL1 IRQ path, already has IRQs disabled, so local_irq_disable() is redundant. - irqentry_exit_to_kernel_mode_preempt() immediately returns when exiting from an NMI-like context, so calling local_irq_disable() beforehand is unnecessary work. Furthermore, it confuses the pNMI state tracking when we are in a context with interrupts disabled and the GIC_PRIO_PSR_I_SET bit is set in the PMR, leading to a warning when CONFIG_ARM64_DEBUG_PRIORITY_MASKING=y: WARNING: ./arch/arm64/include/asm/irqflags.h:63 at arm64_exit_to_kernel_mode+0xb8/0xc0, CPU#40: retsnoop/31805 CPU: 40 UID: 0 PID: 31805 Comm: retsnoop Not tainted 7.2.0-rc6-next-20260805 #7 PREEMPTLAZY pstate: 234013c9 (nzCv DAIF +PAN -UAO +TCO +DIT +SSBS BTYPE=--) pc : arm64_exit_to_kernel_mode (arch/arm64/kernel/entry-common.c:63) lr : el1_abort (arch/arm64/kernel/entry-common.c:323) pmr: 000000f0 Call trace: arm64_exit_to_kernel_mode (arch/arm64/kernel/entry-common.c:63) (P) el1_abort (arch/arm64/kernel/entry-common.c:323) el1h_64_sync_handler (arch/arm64/kernel/entry-common.c:449) el1h_64_sync (arch/arm64/kernel/entry.S:589) [...] Split arm64_exit_to_kernel_mode() into preempt, non-preempt, and dispatch parts so that we can avoid this extra work where it is not needed and avoid breaking the pNMI tracking logic. Reported-by: Breno Leitao Fixes: ae654112eac0 ("arm64: entry: Use split preemption logic") Link: https://lore.kernel.org/all/20260807-arm64_fix-v1-1-d069ccf9d71b@debian.org/ Reviewed-by: Jinjie Ruan Signed-off-by: Vladimir Murzin Signed-off-by: Will Deacon Signed-off-by: Sasha Levin

arm64: Disable KCSAN instrumentation in delay.o

2026-09-14T11:40:36+00:00

[ Upstream commit 5eaec4cf41a8f5ac1a0c69a607cdc5035a797f73 ] KCSAN relies on udelay() for injecting delays. To avoid recursively triggering a watchpoint, where KCSAN sets up watchpoint on an address that is accessed by udelay() in the same thread, disable instrumentation in arm64's delay implementation. Paul found a manifestation of this as follows: | BUG: KCSAN: data-race in __delay / set_need_resched_current | | read (marked) to 0xffff000005899b48 of 8 bytes by interrupt on cpu 8: | __delay+0xb0/0x378 | __udelay+0x4c/0x60 | kcsan_setup_watchpoint+0x3b4/0x820 | __tsan_unaligned_write4+0x228/0x26c | set_need_resched_current+0x138/0x1a8 | rcu_exp_handler+0x418/0x4a0 | __flush_smp_call_function_queue+0x36c/0x4a0 | generic_smp_call_function_single_interrupt+0x20/0x30 | ipi_handler+0xec/0x558 | handle_percpu_devid_irq+0x220/0x2a0 | generic_handle_domain_irq+0x84/0xb4 | gic_handle_irq+0x64/0x144 | call_on_irq_stack+0x30/0x48 | do_interrupt_handler+0x80/0xb8 | el1_interrupt+0x3c/0x60 | el1h_64_irq_handler+0x18/0x24 | el1h_64_irq+0x6c/0x70 | smp_call_function_single+0x18c/0x25c | sync_rcu_exp_select_node_cpus+0x534/0x8bc | rcu_exp_sel_wait_wake+0x358/0xef4 | wait_rcu_exp_gp+0x30/0x44 | kthread_worker_fn+0x1b4/0x5dc | kthread+0x1d8/0x204 | ret_from_fork+0x10/0x20 | | write to 0xffff000005899b4c of 4 bytes by interrupt on cpu 8: | set_need_resched_current+0x138/0x1a8 | [...] This matches what is already done in arch/x86/lib/Makefile. Reported-by: "Paul E. McKenney" Fixes: dd03762ab608 ("arm64: Enable KCSAN") Signed-off-by: Marco Elver Signed-off-by: Will Deacon Signed-off-by: Sasha Levin

arm64: dts: turris-mox: fix usb3 phys

2026-09-14T11:40:33+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

bpf, arm64: Fix exception table metadata for arena load-acquire

2026-09-14T11:40:28+00:00

[ Upstream commit af22d273aa1f61fb86ec712b3ed785da73c3296e ] Same problem as on x86-64: add_exception_handler() decides whether an instruction is a load by its class, and a load-acquire is of BPF_STX class even though it reads from src_reg into dst_reg. As a result ... if (BPF_CLASS(insn->code) != BPF_LDX) dst_reg = DONT_CLEAR; ... drops the register to clear, and ... if (BPF_CLASS(insn->code) == BPF_LDX) arena_reg = bpf2a64[insn->src_reg]; else arena_reg = bpf2a64[insn->dst_reg]; ... hands ex_handler_bpf() the value register instead of the address register. A load-acquire from an arena pointer that faults on an unmapped page is therefore reported as a WRITE at a bogus address, and dst_reg keeps its previous value instead of being cleared to 0. Note that emit_atomic_ld_st() already picks src_reg as the address for BPF_LOAD_ACQ, so only the exception table metadata was out of sync with the emitted access. Same as on x86-64, use bpf_atomic_is_load_acq() so a load-acquire takes the load path. Fixes: 9bb12368d539 ("bpf, arm64: Support load-acquire and store-release instructions") Signed-off-by: Daniel Borkmann Reviewed-by: Puranjay Mohan Link: https://lore.kernel.org/bpf/20260806201047.333389-4-daniel@iogearbox.net Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin