Re: [RESEND Patch v10 19/23] perf/x86: Support SSP sampling using sample_regs_* fields

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Critical] Arbitrary kernel memory read or kernel panic (page fault) via out-of-bounds pointer dereference in `perf_reg_value()` when triggering a hardware event via BPF.
--

--- Patch [19]: [RESEND Patch v10 19/23] perf/x86: Support SSP sampling using sample_regs_* fields ---
commit f68aca90e443a6b899f0ff2729c1f378ec1fb548
Author: Dapeng Mi <dapeng1.mi@linux.intel.com>

perf/x86: Support SSP sampling using sample_regs_* fields

This commit adds support for sampling the CET SSP register via the
sample_regs_* fields. It uses the spare space reclaimed from the original
XMM space and is gated behind the sample_simd_regs_enabled flag.

> diff --git a/arch/x86/kernel/perf_regs.c b/arch/x86/kernel/perf_regs.c
> index 7d4233ed859cd..f8952f7c36cce 100644
> --- a/arch/x86/kernel/perf_regs.c
> +++ b/arch/x86/kernel/perf_regs.c
> @@ -72,6 +72,11 @@ u64 perf_reg_value(struct pt_regs *regs, int idx)
>  					return 0;
>  				return perf_regs->egpr_regs[idx - PERF_REG_X86_R16];
>  			}
> +			if (idx == PERF_REG_X86_SSP) {
> +				if (!perf_regs->ssp)
> +					return 0;
> +				return *perf_regs->ssp;
> +			}

[Severity: Critical]
This is a pre-existing issue, but does this function correctly handle the case
where regs is not embedded in a struct x86_perf_regs?

If a hardware event is added to a BPF_MAP_TYPE_PERF_EVENT_ARRAY map and
triggered by a BPF program calling bpf_perf_event_output(),
perf_prepare_sample() uses the raw pt_regs from the BPF context.
perf_sample_regs_user() then sets the sample's user regs to
task_pt_regs(current).

When perf_output_sample_regs() subsequently calls perf_reg_value(), it blindly
casts this raw pt_regs pointer to struct x86_perf_regs using container_of():

arch/x86/kernel/perf_regs.c:perf_reg_value() {
    ...
    if (idx > PERF_REG_X86_R15) {
        perf_regs = container_of(regs, struct x86_perf_regs, regs);
        if (perf_regs->abi == PERF_SAMPLE_REGS_ABI_NONE)
            return 0;
    ...
}

Since task_pt_regs(current) is located at the very end of the task's stack
page, reading fields like the abi or xmm_regs pointer accesses the vmap stack
guard page, which can trigger a kernel panic. Can this be avoided by verifying
the origin of the regs pointer before casting?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260824082731.1013973-1-dapeng1.mi@linux.intel.com?part=19