Re: [RFC PATCH v2 2/3] sparc64: Support PERF_SAMPLE_REGS_USER and PERF_SAMPLE_STACK_USER

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] perf: sparc64: infoleak of uninitialized kernel stack via PERF_REG_SPARC_G0
- [Medium] perf: sparc64: PERF_SAMPLE_STACK_USER fails due to 2047-byte stack bias
--

commit dc2931cc8aec6bb17c7d08c4adfcf954bfdf3a68
Author: Stian Halseth <stian@itx.no>

sparc64: Support PERF_SAMPLE_REGS_USER and PERF_SAMPLE_STACK_USER
    
Select HAVE_PERF_REGS and HAVE_PERF_USER_STACK_DUMP and add the
perf_regs implementation. The exposed registers mirror struct pt_regs:
%g0-%g7, %o0-%o7 (named from the user's point of view; pt_regs calls
them UREG_I*), %tstate, PC, NPC and %y.

> diff --git a/arch/sparc/kernel/perf_regs.c b/arch/sparc/kernel/perf_regs.c
> new file mode 100644
> index 0000000000000..726516abf5a74
> --- /dev/null
> +++ b/arch/sparc/kernel/perf_regs.c
> @@ -0,0 +1,65 @@
> +// SPDX-License-Identifier: GPL-2.0
> +#include <linux/perf_event.h>
> +#include <linux/perf_regs.h>
> +#include <linux/sched/task_stack.h>
> +#include <asm/cacheflush.h>
> +#include <asm/ptrace.h>
> +
> +u64 perf_reg_value(struct pt_regs *regs, int idx)
> +{
> +	u64 val;
> +
> +	switch (idx) {
> +	case PERF_REG_SPARC_G0 ... PERF_REG_SPARC_O7:
> +		val = regs->u_regs[idx];
> +		break;

[Severity: High]
Since %g0 is hardwired to zero on the SPARC architecture, the trap entry
code does not save it into the PT_V9_G0 slot (u_regs[0]) of the pt_regs
structure on the kernel stack.

When an unprivileged user configures a perf event to sample
PERF_SAMPLE_REGS_USER or PERF_SAMPLE_REGS_INTR and requests the %g0
register (where idx=0), does returning regs->u_regs[0] here expose
uninitialized kernel stack memory to userspace per sample?

[Severity: Medium]
For PERF_REG_SPARC_O6 (%sp), returning the raw register means the stack
pointer remains biased by 2047 bytes on SPARC64.

While the commit message notes this biased address is expected by
consumers, when perf_output_sample_ustack() attempts to copy the stack, it
will start 2047 bytes below the actual mapped stack frame.

Could this high probability (~25% for 8KB pages) of starting in an unmapped
page cause __copy_from_user_inatomic() to immediately fault and abort the
copy? Would this result in a 0-byte dynamic stack dump even for perfectly
valid stack frames, breaking userspace DWARF unwinding and profiling tools?

> +	case PERF_REG_SPARC_TSTATE:
> +		return regs->tstate;
> +	case PERF_REG_SPARC_PC:
> +		val = regs->tpc;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260922201507.1719668-1-stian@itx.no?part=2