arch/riscv/kernel/ptrace.c | 6 ++++++ 1 file changed, 6 insertions(+)
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 <cp0613@linux.alibaba.com>
---
This follows the behaviour of the arm64 GCS regset. Unlike vector
registers, no ENODATA case applies here: the CFI status regset has a
valid all-zero representation even when CFI has not been enabled for
the traced task.
is_user_lpad_enabled()/is_user_shstk_enabled() are used instead of a
plain ISA check so that the regset visibility matches what userspace
can actually use via prctl: both helpers also honor the
riscv_nousercfi kernel command line switch.
arch/riscv/kernel/ptrace.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/riscv/kernel/ptrace.c b/arch/riscv/kernel/ptrace.c
index f336a183667e..566856e42f65 100644
--- a/arch/riscv/kernel/ptrace.c
+++ b/arch/riscv/kernel/ptrace.c
@@ -299,6 +299,9 @@ static int riscv_cfi_get(struct task_struct *target,
struct user_cfi_state user_cfi;
struct pt_regs *regs;
+ if (!is_user_lpad_enabled() && !is_user_shstk_enabled())
+ return -EINVAL;
+
memset(&user_cfi, 0, sizeof(user_cfi));
regs = task_pt_regs(target);
@@ -337,6 +340,9 @@ static int riscv_cfi_set(struct task_struct *target,
struct user_cfi_state user_cfi;
struct pt_regs *regs;
+ if (!is_user_lpad_enabled() && !is_user_shstk_enabled())
+ return -EINVAL;
+
regs = task_pt_regs(target);
ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf, &user_cfi, 0, -1);
--
2.50.1
On Thu, Aug 20, 2026 at 2:32 PM Chen Pei <cp0613@linux.alibaba.com> wrote:
>
> 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")
Cc: stable@vger.kernel.org
> Signed-off-by: Chen Pei <cp0613@linux.alibaba.com>
> ---
> This follows the behaviour of the arm64 GCS regset. Unlike vector
> registers, no ENODATA case applies here: the CFI status regset has a
> valid all-zero representation even when CFI has not been enabled for
> the traced task.
>
> is_user_lpad_enabled()/is_user_shstk_enabled() are used instead of a
> plain ISA check so that the regset visibility matches what userspace
> can actually use via prctl: both helpers also honor the
> riscv_nousercfi kernel command line switch.
>
> arch/riscv/kernel/ptrace.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/riscv/kernel/ptrace.c b/arch/riscv/kernel/ptrace.c
> index f336a183667e..566856e42f65 100644
> --- a/arch/riscv/kernel/ptrace.c
> +++ b/arch/riscv/kernel/ptrace.c
> @@ -299,6 +299,9 @@ static int riscv_cfi_get(struct task_struct *target,
> struct user_cfi_state user_cfi;
> struct pt_regs *regs;
>
> + if (!is_user_lpad_enabled() && !is_user_shstk_enabled())
Do you want:
/* If shadow stack is not supported or not enabled, nothing to ... */
if (!is_user_shstk_enabled() || !is_shstk_enabled(tsk))
> + return -EINVAL;
> +
> memset(&user_cfi, 0, sizeof(user_cfi));
> regs = task_pt_regs(target);
>
> @@ -337,6 +340,9 @@ static int riscv_cfi_set(struct task_struct *target,
> struct user_cfi_state user_cfi;
> struct pt_regs *regs;
>
> + if (!is_user_lpad_enabled() && !is_user_shstk_enabled())
> + return -EINVAL;
> +
> regs = task_pt_regs(target);
>
> ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf, &user_cfi, 0, -1);
> --
> 2.50.1
>
--
Best Regards
Guo Ren
Hi Guo Ren, Thanks for the review. On 2026/8/20 19:45, Guo Ren wrote: > On Thu, Aug 20, 2026 at 2:32 PM Chen Pei <cp0613@linux.alibaba.com> wrote: >> + if (!is_user_lpad_enabled() && !is_user_shstk_enabled()) > Do you want: > > /* If shadow stack is not supported or not enabled, nothing to ... */ > if (!is_user_shstk_enabled() || !is_shstk_enabled(tsk)) There are two separate points here, let me clarify both. First, on "&&" vs "||" between the two features: the combined check is intentional. Zicfilp and Zicfiss are independent extensions and the kernel treats them as such everywhere (separate hwprobe keys, separate prctls, separate riscv_nousercfi switches). Rejecting the regset as soon as either one is missing would also take away the useful part: on a system with only shadow stack, shstk_ptr is exactly what a debugger needs for shadow stack unwinding, and symmetrically for landing pads. With "&&", the regset stays available when at least one feature is present, and the missing feature's section reads as all-zero, which is accurate: its per-task enable flags can only be set when the feature is available, since the prctl paths are gated by is_user_lpad_enabled()/is_user_shstk_enabled() individually. The same applies to riscv_cfi_set(): a "||" would wrongly block legitimate shstk_ptr updates on shadow-stack-only systems. Second, on the per-task check (is_shstk_enabled(target) and friends): I would prefer not to reject the access when CFI is simply not enabled on the traced task. The all-zero state is a meaningful answer -- it tells the debugger that CFI is not enabled for this task. This matches the arm64 GCS regset, which only checks system support in gcs_get() and returns the task's (possibly zero) state unconditionally. Best regards, Pei
© 2016 - 2026 Red Hat, Inc.