laptop-kernel/arch/riscv, branch master

Merge tag 'soc-fixes-7.3-3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc

2026-10-15T22:10:26Z

Pull SoC fixes from Arnd Bergmann: "A small number of last minute bug fixes came up since LPC. Most of these are for devicetree files: - Tegra264 needs fan descriptions to keep the system from overheating - A cleanup on TI DRA7 caused a regression on PCI support and needs a fixup - The beaglev-fire board can no longer probe the mcp3564 sensor after a an inconsistent update in 7.1 - A few fixes address compile time dtc warnings on tegra The other three patches are all addressing minor problems in tegra drivers and the sama5 defconfig" * tag 'soc-fixes-7.3-3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: ARM: configs: sama5: enable current Microchip KSZ DSA symbols soc/tegra: pmc: Fix uninitialised clock rate riscv: dts: microchip: beaglev-fire: remove double definition of gpio interrupts ARM: dts: ti/omap: dra7: fix PCIe PHY clock divider definition soc/tegra: fuse: Add missing newline to APBMISC error message arm64: tegra: Add PCIe root ports on Tegra264 arm64: tegra: Reorder reg and reg-names to match bindings arm64: tegra: Add PWM fan on Jetson AGX Thor DevKit arm64: tegra: Add PWM controllers on Tegra264

Merge tag 'riscv-dt-fixes-for-v7.3-rc' of https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux into arm/fixes

2026-10-12T07:19:45Z

RISC-V devicetrees fixes for v7.3-rc Microchip: Remove double definition of interrupts on the BeagleV-Fire, which cause the sensor to be associated the wrong plic interrupt. Signed-off-by: Conor Dooley * tag 'riscv-dt-fixes-for-v7.3-rc' of https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux: riscv: dts: microchip: beaglev-fire: remove double definition of gpio interrupts

riscv: fix load_unaligned_zeropad() fixup for RV32

2026-10-08T02:25:09Z

The fixup for load_unaligned_zeropad() runs when REG_L crosses into an unmapped page. REG_L is lw on RV32 and ld on RV64, but the fixup assumes an 8-byte load: it rounds the address down to 8 bytes and derives the shift from three address bits. On RV32, a load starting in the last three bytes of a mapped page selects the word four bytes earlier and shifts it by 40, 48, or 56 bits, more than the register width. The caller gets earlier bytes instead of the string tail followed by zeroes. This affects RV32 MMU kernels built with RISCV_EFFICIENT_UNALIGNED_ACCESS=y, which selects DCACHE_WORD_ACCESS and lets dcache name hashing and comparison and strscpy() use this path. Derive the alignment and offset masks from sizeof(data) instead of a fixed 8. This makes RV32 use the correct source word. RV64 code is unchanged: the complete extable.o is byte-for-byte identical before and after. Fixes: d0fdc20b0429 ("riscv: select DCACHE_WORD_ACCESS for efficient unaligned access HW") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Karl Mehltretter Reviewed-by: Jisheng Zhang Link: https://patch.msgid.link/20260907190750.26303-1-kmehltretter@gmail.com Signed-off-by: Paul Walmsley

riscv: entry: gate shadow call stack reload on sstatus.SPP, not tp

2026-10-08T01:38:05Z

Under CONFIG_SHADOW_CALL_STACK, handle_exception() reloads the kernel shadow call stack pointer (gp) only when the trap came from userspace. It made that decision with scs_load_current_if_task_changed, which compares the trap-time tp (read back from sscratch into s5) against the current tp: beq \prev, tp, _skip_scs scs_load_current _skip_scs: tp is a user-writable register. A user task that sets tp to the linear-map address of its own task_struct (¤t) before trapping makes the comparison succeed (can achieve by brute force with KASLR enable under our test), so the kernel skips scs_load_current and keeps running with the gp that userspace left in place. Under CONFIG_SHADOW_CALL_STACK gp is the shadow call stack pointer and load_global_pointer is a no-op, so the compiler-emitted "sd ra, -8(gp)" / "ld ra, -8(gp)" in every non-leaf function then write to, and return through, an attacker-controlled address -- an unprivileged kernel arbitrary-write and control-flow-hijack primitive. The poisoned gp is saved to task_struct.scs_sp on return, so the reload is skipped on every subsequent entry as well. Decide "came from userspace" from the hardware sstatus.SPP bit (already in s1 at this point) instead of from tp, mirroring the check that ret_from_exception already uses a few instructions later. SPP is written by hardware on trap entry and cannot be forged from U-mode. Legitimate behaviour is unchanged: user entries (SPP=0) reload the task shadow call stack, nested kernel entries (SPP=1) skip it. Fixes: d1584d791a29 ("riscv: Implement Shadow Call Stack") Signed-off-by: Ziyi Guo Reviewed-by: Sami Tolvanen Link: https://patch.msgid.link/20261001135711.934152-1-guoziyi114@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Paul Walmsley

riscv: ptrace: Zero-initialize regset buffers before copyin

2026-10-07T16:44:54Z

user_regset_copyin() only copies `count` bytes, so a PTRACE_SETREGSET request with a short iov_len leaves the rest of the stack buffer uninitialized. In riscv_vr_set() that garbage is validated and copied into the target's vstate, and in riscv_cfi_set() it can be stored as the target's shadow stack pointer. Zero both buffers, as the get path already does. Fixes: 9300f0043974 ("RISC-V: Add ptrace support for vectors") Fixes: 2af7c9cf021c ("riscv/ptrace: expose riscv CFI status and state via ptrace and in core files") Signed-off-by: Zongmin Zhou Link: https://patch.msgid.link/20260826115711.86861-1-min_halo@163.com Signed-off-by: Paul Walmsley

riscv: ptrace: reject CFI regset access when extensions are absent

2026-10-07T15:35:41Z

riscv_cfi_get() and riscv_cfi_set() do not check whether the Zicfilp or Zicfiss extensions are present. On systems without them, PTRACE_GETREGSET on REGSET_CFI still succeeds and returns a zeroed user_cfi_state, misleading debuggers into believing the register set is available, and PTRACE_SETREGSET silently accepts writes that have no effect (e.g. clearing SR_ELP). Reject the access with -EINVAL when neither branch landing pads nor shadow stack is available to userspace, using the same availability helpers as the prctl path. Fixes: 2af7c9cf021c ("riscv/ptrace: expose riscv CFI status and state via ptrace and in core files") Signed-off-by: Chen Pei Link: https://patch.msgid.link/20260820063233.2567-1-cp0613@linux.alibaba.com Cc: stable@vger.kernel.org Signed-off-by: Paul Walmsley

riscv: fix NR_CPUS range leaking 64-bit default onto 32-bit builds

2026-10-07T15:08:03Z

rv32_defconfig is built in two stages: - the generic (64-bit-oriented) "defconfig" target runs first and resolves a concrete NR_CPUS value using the 64BIT default. - then 32-bit.config is merged on top via merge_config.sh, which does not touch NR_CPUS. The final "make olddefconfig" pass sees NR_CPUS=256 is still within the "2 512" range therefore never recalculates it against the 32BIT default of 32, silently keeping the leaked 64-bit-stage value. The NR_CPUS-scaled regions (percpu areas, ...etc) of the resulting CONFIG_NR_CPUS=256 on a 32-bit build bloats and does not fit in the percpu/stack layout for rv32 and hangs early boot on QEMU's virt machine. Fix this by explicitly specify the range for 32/64 and SBI_V01/!SBI_V01. Fixes: 0fa749771993 ("riscv: Raise default NR_CPUS for 64BIT to 256") Signed-off-by: Leo Yu-Chi Liang Link: https://patch.msgid.link/20261007045229.36114-1-leo.liang@sifive.com Signed-off-by: Paul Walmsley

riscv: errata: select RISCV_ALTERNATIVE_EARLY for THEAD GHOSTWRITE

2026-10-07T15:03:19Z

errata_probe_ghostwrite() only marks the CPU as vulnerable when it is called at the RISCV_ALTERNATIVES_EARLY_BOOT stage, and the mitigation in ghostwrite_enable_mitigation() only takes effect if the vulnerable state was recorded before the boot alternatives are patched. The early boot stage is only executed when CONFIG_RISCV_ALTERNATIVE_EARLY is enabled, which currently is only selected by ERRATA_THEAD_MAE. In a kernel built with ERRATA_THEAD_GHOSTWRITE=y but ERRATA_THEAD_MAE=n, the early alternatives never run, so ghostwrite_state is never set to VULNERABLE: ghostwrite_enable_mitigation() returns false, xtheadvector remains enabled, and sysfs reports "Not affected" on a vulnerable T-Head C9xx CPU. Select RISCV_ALTERNATIVE_EARLY from ERRATA_THEAD_GHOSTWRITE so that the vulnerability is detected in the early boot stage and the default mitigation is applied. Fixes: 4bf97069239b ("riscv: Add ghostwrite vulnerability") Signed-off-by: Zongmin Zhou Link: https://patch.msgid.link/20260917074843.52716-1-min_halo@163.com Cc: stable@vger.kernel.org Signed-off-by: Paul Walmsley

riscv: futex: untag the user pointer before the atomic access

2026-10-07T14:44:06Z

access_ok() checks untagged_addr(uaddr), but arch_futex_atomic_op_inuser() and futex_atomic_cmpxchg_inatomic() hand the raw uaddr to the inline asm amoswap/amoadd/.../lr.w+sc.w through the "+m" (*uaddr) operand. When the tagged address ABI is enabled (CONFIG_RISCV_ISA_SUPM, prctl PR_SET_TAGGED_ADDR_CTRL with PMLEN != 0), those two addresses differ: a user pointer whose top PMLEN bits hold a tag passes access_ok() after untagging, but the atomic is then performed on the still-tagged raw address. Supervisor-mode data accesses are not subject to the U-mode pointer masking (that is governed by menvcfg.PMM, which the kernel does not set), so hardware does not strip the tag for the kernel's own access. With Sv57 and PMLEN=16 the tag bits overlap the canonical-address bits, so a tagged pointer can name a canonical kernel virtual address (e.g. in the linear map) whose untagged form is a valid user address. An unprivileged process can thus make FUTEX_WAKE_OP perform an atomic read-modify-write on an arbitrary kernel address, with the matching FUTEX_OP_CMP_* result serving as a read oracle. get_user()/put_user()/raw_copy_{to,from}_user() already untag the pointer after the access_ok() check; do the same in the futex helpers so the atomic operates on the address that was actually validated. Fixes: 2e1743085887 ("riscv: Add support for the tagged address ABI") Reviewed-by: Samuel Holland Signed-off-by: Ziyi Guo Link: https://patch.msgid.link/20261006140200.877263-1-guoziyi114@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Paul Walmsley

riscv: lib: Fix ZBB strnlen wrap-around regression on huge counts

2026-10-06T01:02:38Z

The aligned scan boundary is derived from the last valid byte, (s + count - 1). When count is huge (e.g. SIZE_MAX, which FORTIFY strcat/strlcat pass when the destination size is not known at compile time), s + count wraps around and the boundary lands before s, so the ZBB path returns a bogus length. The original implementation (5ba15d419fab) had the same wrap-around in its (s + count) & ~7 boundary computation; after 5d588c684833 the wrapped boundary is caught by the pre-loop guard "bgeu t0, t4, 2f", which then always exits for aligned strings of 8 or more characters and strnlen() returns 8 instead of the real length. This silently truncates strings built by fortified strcat: the dm sysfs name attribute shows "live-bas" instead of "live-base", the truncated name pollutes the udev database, and blivet/anaconda (as well as LVM/dm-crypt/multipath userspace) break on RISC-V systems. Detect the wrap-around and saturate the boundary to the top of the address space, making the scan equivalent to strlen(). The saturation clamps the increment to ~s, so it stays branchless and wrap-free: s + min(count - 1, ~s) == saturating_add(s, count - 1) Normal counts are unaffected. Fixes: 5ba15d419fab ("riscv: lib: add strnlen() implementation") Cc: stable@vger.kernel.org Suggested-by: David Laight Suggested-by: Qingfang Deng Signed-off-by: Shao Mingyin Acked-by: Michael Neuling Tested-by: Troy Mitchell Reviewed-by: Aurelien Jarno Link: https://patch.msgid.link/20260915152656708z04s4oSYY2BGj34F36RZa@zte.com.cn Signed-off-by: Paul Walmsley