linux-stable.git/arch/riscv/kernel/entry.S, branch linux-rolling-stable

riscv: mm: Unconditionally sfence.vma for spurious fault

2026-07-18T14:55:44+00:00

commit 1b2c6b56a9fa0dcbef461039937de22b1cbecc7d upstream.

Svvptc does not guarantee that it's safe to just return here. Since we
have already cleared our bit, if, theoretically, the bounded timeframe
for the accessed page to become valid still hasn't happened after sret,
we could fault again and actually crash.

Hopefully, these spurious faults should be rare enough that this is an
acceptable slowdown.

Cc: stable@vger.kernel.org
Fixes: 503638e0babf ("riscv: Stop emitting preventive sfence.vma for new vmalloc mappings")
Signed-off-by: Vivian Wang 
Link: https://patch.msgid.link/20260303-handle-kfence-protect-spurious-fault-v2-5-f80d8354d79d@iscas.ac.cn
Signed-off-by: Paul Walmsley 
Signed-off-by: Greg Kroah-Hartman

riscv: kfence: Call mark_new_valid_map() for kfence_unprotect()

2026-07-04T11:45:07+00:00

commit 8d6c8c40e733b3fcaf92fed0a078bba2f6941a3b upstream.

In kfence_protect_page(), which kfence_unprotect() calls, we cannot send
IPIs to other CPUs to ask them to flush TLB. This may lead to those CPUs
spuriously faulting on a recently allocated kfence object despite it
being valid, leading to false positive use-after-free reports.

Fix this by calling mark_new_valid_map() so that the page fault handling
code path notices the spurious fault and flushes TLB then retries the
access.

Update the comment in handle_exception to indicate that
new_valid_map_cpus_check also handles kfence_unprotect() spurious
faults.

Note that kfence_protect() has the same stale TLB entries problem, but
that leads to false negatives, which is fine with kfence.

Cc: stable@vger.kernel.org
Reported-by: Yanko Kaneti 
Fixes: b3431a8bb336 ("riscv: Fix IPIs usage in kfence_protect_page()")
Signed-off-by: Vivian Wang 
Link: https://patch.msgid.link/20260303-handle-kfence-protect-spurious-fault-v2-2-f80d8354d79d@iscas.ac.cn
Signed-off-by: Paul Walmsley 
Signed-off-by: Greg Kroah-Hartman

riscv: add hardware error trap handler support

2026-04-05T00:42:44+00:00

Add support for handling hardware error traps (exception code 19)
in the RISC-V architecture. The changes include:

- Add do_trap_hardware_error function declaration in asm-prototypes.h
- Add hardware error trap vector entry in entry.S exception vector table
- Implement do_trap_hardware_error handler in traps.c that generates
  SIGBUS with BUS_MCEERR_AR for hardware errors

This enables proper handling of hardware error exceptions that may occur
in RISC-V systems, providing appropriate error reporting and signal
generation for user space processes.

Signed-off-by: Rui Qi 
Link: https://patch.msgid.link/20260202094200.53735-1-qirui.001@bytedance.com
[pjw@kernel.org: clean up commit message slightly]
Signed-off-by: Paul Walmsley

riscv/traps: Introduce software check exception and uprobe handling

2026-01-29T09:38:40+00:00

The Zicfiss and Zicfilp extensions introduce a new exception, the
'software check exception', in the privileged ISA, with cause code =
18. This patch implements support for software check exceptions.

Additionally, the patch implements a CFI violation handler which
checks the code in the xtval register. If xtval=2, the software check
exception happened because of an indirect branch that didn't land on a
4 byte aligned PC or on a 'lpad' instruction, or the label value
embedded in 'lpad' didn't match the label value set in the x7
register. If xtval=3, the software check exception happened due to a
mismatch between the link register (x1 or x5) and the top of shadow
stack (on execution of `sspopchk`).

In case of a CFI violation, SIGSEGV is raised with code=SEGV_CPERR.
SEGV_CPERR was introduced by the x86 shadow stack patches.

To keep uprobes working, handle the uprobe event first before
reporting the CFI violation in the software check exception
handler. This is because, when the landing pad is activated, if the
uprobe point is set at the lpad instruction at the beginning of a
function, the system triggers a software check exception instead of an
ebreak exception due to the exception priority. This would prevent
uprobe from working.

Reviewed-by: Zong Li
Co-developed-by: Zong Li
Signed-off-by: Zong Li
Signed-off-by: Deepak Gupta
Tested-by: Andreas Korb # QEMU, custom CVA6
Tested-by: Valentin Haudiquet
Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-15-b55691eacf4f@rivosinc.com
[pjw@kernel.org: cleaned up the patch description]
Signed-off-by: Paul Walmsley

riscv: Implement indirect branch tracking prctls

2026-01-29T09:38:40+00:00

This patch adds a RISC-V implementation of the following prctls:
PR_SET_INDIR_BR_LP_STATUS, PR_GET_INDIR_BR_LP_STATUS and
PR_LOCK_INDIR_BR_LP_STATUS.

Reviewed-by: Zong Li 
Signed-off-by: Deepak Gupta 
Tested-by: Andreas Korb 
Tested-by: Valentin Haudiquet 
Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-14-b55691eacf4f@rivosinc.com
[pjw@kernel.org: clean up patch description]
Signed-off-by: Paul Walmsley

riscv: Add usercfi state for task and save/restore of CSR_SSP on trap entry/exit

2026-01-26T04:09:53+00:00

Carve out space in the RISC-V architecture-specific thread struct for
cfi status and shadow stack in usermode.

This patch:
- defines a new structure cfi_status with status bit for cfi feature
- defines shadow stack pointer, base and size in cfi_status structure
- defines offsets to new member fields in thread in asm-offsets.c
- saves and restores shadow stack pointer on trap entry (U --> S) and exit
  (S --> U)

Shadow stack save/restore is gated on feature availability and is
implemented using alternatives. CSR_SSP can be context-switched in
'switch_to' as well, but as soon as kernel shadow stack support gets
rolled in, the shadow stack pointer will need to be switched at trap
entry/exit point (much like 'sp'). It can be argued that a kernel
using a shadow stack deployment scenario may not be as prevalent as
user mode using this feature. But even if there is some minimal
deployment of kernel shadow stack, that means that it needs to be
supported.  Thus save/restore of shadow stack pointer is implemented
in entry.S instead of in 'switch_to.h'.

Reviewed-by: Charlie Jenkins 
Reviewed-by: Zong Li 
Reviewed-by: Alexandre Ghiti 
Signed-off-by: Deepak Gupta 
Tested-by: Andreas Korb  # QEMU, custom CVA6
Tested-by: Valentin Haudiquet 
Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-5-b55691eacf4f@rivosinc.com
[pjw@kernel.org: cleaned up patch description]
Signed-off-by: Paul Walmsley

riscv: entry: fix typo in comment 'instruciton' -> 'instruction'

2025-10-10T01:36:45+00:00

Fix a typo in a comment in the RISC-V entry.S.

Signed-off-by: Florian Schmaus 
Link: https://lore.kernel.org/r/20251006093742.53925-1-flo@geekplace.eu
[pjw@kernel.org: wrote a basic patch description]
Signed-off-by: Paul Walmsley

riscv: errata: Fix the PAUSE Opcode for MIPS P8700

2025-09-19T16:33:56+00:00

Add ERRATA_MIPS and ERRATA_MIPS_P8700_PAUSE_OPCODE configs.
Handle errata for the MIPS PAUSE instruction.

Signed-off-by: Djordje Todorovic 
Signed-off-by: Aleksandar Rikalo 
Signed-off-by: Raj Vishwanathan4 
Signed-off-by: Aleksa Paunovic 
Reviewed-by: Alexandre Ghiti 
Link: https://lore.kernel.org/r/20250724-p8700-pause-v5-7-a6cbbe1c3412@htecgroup.com
[pjw@kernel.org: updated to apply and compile; fixed a checkpatch issue]
Signed-off-by: Paul Walmsley

riscv: use lw when reading int cpu in new_vmalloc_check

2025-09-05T21:30:45+00:00

REG_L is wrong, because thread_info.cpu is 32-bit, not xlen-bit wide.
The struct currently has a hole after cpu, so little endian accesses
seemed fine.

Fixes: 503638e0babf ("riscv: Stop emitting preventive sfence.vma for new vmalloc mappings")
Cc: stable@vger.kernel.org
Reviewed-by: Alexandre Ghiti 
Signed-off-by: Radim Krčmář 
Link: https://lore.kernel.org/r/20250725165410.2896641-4-rkrcmar@ventanamicro.com
Signed-off-by: Paul Walmsley

stackleak: Rename STACKLEAK to KSTACK_ERASE

2025-07-22T04:35:01+00:00

In preparation for adding Clang sanitizer coverage stack depth tracking
that can support stack depth callbacks:

- Add the new top-level CONFIG_KSTACK_ERASE option which will be
  implemented either with the stackleak GCC plugin, or with the Clang
  stack depth callback support.
- Rename CONFIG_GCC_PLUGIN_STACKLEAK as needed to CONFIG_KSTACK_ERASE,
  but keep it for anything specific to the GCC plugin itself.
- Rename all exposed "STACKLEAK" names and files to "KSTACK_ERASE" (named
  for what it does rather than what it protects against), but leave as
  many of the internals alone as possible to avoid even more churn.

While here, also split "prev_lowest_stack" into CONFIG_KSTACK_ERASE_METRICS,
since that's the only place it is referenced from.

Suggested-by: Ingo Molnar 
Link: https://lore.kernel.org/r/20250717232519.2984886-1-kees@kernel.org
Signed-off-by: Kees Cook