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

["Mi, Dapeng" <dapeng1.mi@linux.intel.com>]

On 8/24/2026 5:39 PM, sashiko-bot@kernel.org wrote:
> 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?

Same concern with patch 13/23 "perf/x86: Support XMM sampling using
sample_simd_vec_reg_* fields". Copy the comments here.

"

This concern would never happen. Currently any event trying to sample SIMD
and other extended registers would check if its PMU supports the
PERF_PMU_CAP_SIMD_REGS or PERF_PMU_CAP_EXTENDED_REGS (XMM) capability. If
not, the event creation would fail at the beginning. Thanks.

    if (!(pmu->capabilities & PERF_PMU_CAP_SIMD_REGS) &&
        event_has_simd_regs(event)) {
        ret = -EOPNOTSUPP;
        goto err_destroy;
    }

    if (!(pmu->capabilities & PERF_PMU_CAP_EXTENDED_REGS) &&
        event_has_extended_regs(event)) {
        ret = -EOPNOTSUPP;
        goto err_destroy;
    }

"


>