Re: [Patch v2 3/7] perf/x86: Guard intel_pmu_cpu_dead() against invalid hybrid PMU casts

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Race condition in NMI handler causing out-of-bounds access during hybrid CPU bring-up.
- [High] Unhandled #GP exceptions (kernel panic) in NMI and hotplug paths if hybrid PMU initialization fails.
--

--- Patch [3]: [Patch v2 3/7] perf/x86: Guard intel_pmu_cpu_dead() against invalid hybrid PMU casts ---
commit 419f89d32dfc7abe942483376114f8e4845bc1a8
Author: Dapeng Mi <dapeng1.mi@linux.intel.com>

perf/x86: Guard intel_pmu_cpu_dead() against invalid hybrid PMU casts

In failure paths, cpuc->pmu can point to the global static pmu instead of
an embedded x86_hybrid_pmu::pmu. This commit clears cpuc->pmu to NULL when
check_hw_exists() fails and validates cpuc->pmu before hybrid container
conversion during CPU rollback paths.

> diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
> index b39c6ce0efb5c..a991fc4f1575f 100644
> --- a/arch/x86/events/intel/core.c
> +++ b/arch/x86/events/intel/core.c
[ ... ]
> @@ -6329,8 +6329,10 @@ static bool init_hybrid_pmu(int cpu)
>  
>  	intel_pmu_check_hybrid_pmus(pmu);
>  
> -	if (!check_hw_exists(&pmu->pmu, pmu->cntr_mask, pmu->fixed_cntr_mask))
> +	if (!check_hw_exists(&pmu->pmu, pmu->cntr_mask, pmu->fixed_cntr_mask)) {
> +		cpuc->pmu = NULL;
>  		return false;
> +	}

[Severity: High]
This is a pre-existing issue, but is it possible for an NMI to fire before
this initialization completes during hybrid CPU bring-up?

If a secondary CPU unmasks NMIs early and an NMI fires before the
CPUHP_AP_PERF_X86_STARTING callback executes init_hybrid_pmu(),
perf_event_nmi_handler() will run.

If active_events is greater than zero globally, intel_pmu_handle_irq()
executes:

arch/x86/events/intel/core.c:intel_pmu_handle_irq() {
    ...
    bool late_ack = hybrid_bit(cpuc->pmu, late_ack);
    ...
}

Since cpuc->pmu is statically initialized to the global &pmu at this stage,
could this cause hybrid_pmu() to perform an invalid container_of cast and
lead to an out-of-bounds access?

[Severity: High]
This is a pre-existing issue, but if check_hw_exists() fails and we return
false here, leaving the CPU online without a functioning PMU, could this lead
to unhandled #GP exceptions?

If an NMI fires while active_events is greater than zero globally,
intel_pmu_handle_irq() unconditionally reads PMU MSRs:

arch/x86/events/intel/core.c:intel_pmu_handle_irq() {
    ...
    status = intel_pmu_get_status();
    ...
}

Since check_hw_exists() failed, the MSRs are likely inaccessible. Would
executing rdmsrl() trigger a #GP exception and a kernel panic?

Similarly, during CPU teardown, does intel_pmu_cpu_dying() blindly write to
MSRs without checking if the PMU was successfully initialized?

arch/x86/events/intel/ds.c:fini_arch_pebs_on_cpu() {
    ...
    wrmsrq_on_cpu(cpu, MSR_IA32_PEBS_BASE, 0);
    ...
}

Could this wrmsrq_on_cpu() without fault protection also cause a #GP panic if
PMU initialization had failed?

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