Re: [PATCH V2 2/7] perf/x86/intel/uncore: Guard against invalid box control address

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] The patch guards box-level operations against invalid (0) control addresses when a discovery unit is missing, but it critically misses event-level operations. This omission allows an unprivileged or privileged user running `perf` to trigger a #GP fault (kernel panic) or PCI configuration space corruption.
--

commit 65ddbcdd36196085490e8783cb658d7e20c2e9c5
Author: Zide Chen <zide.chen@intel.com>

perf/x86/intel/uncore: Guard against invalid box control address

This commit guards against a NULL return value from
intel_uncore_find_discovery_unit() before accessing hardware box control
addresses. It prevents potential faults when a CPU die is offline during
uncore enumeration.

> diff --git a/arch/x86/events/intel/uncore_discovery.c b/arch/x86/events/intel/uncore_discovery.c
> index 60e1200c4691d..af2217b44a814 100644
> --- a/arch/x86/events/intel/uncore_discovery.c
> +++ b/arch/x86/events/intel/uncore_discovery.c

[ ... ]

> @@ -549,6 +560,10 @@ bool intel_generic_uncore_assign_hw_event(struct perf_event *event,
>  
>  	if (box->pci_dev) {
>  		box_ctl = UNCORE_DISCOVERY_PCI_BOX_CTRL(box_ctl);
> +
> +		if (!box_ctl)
> +			return false;
> +

[Severity: High]
This is a pre-existing issue, but does returning false here when box_ctl is
invalid still leave us vulnerable to hardware access faults during event
execution?

When intel_generic_uncore_assign_hw_event() returns false, the caller
uncore_assign_hw_event() unconditionally falls back to legacy offset
calculations using uncore_event_ctl(). For discovery PMUs, this results in
hwc->config_base being set to a small relative offset like 0x0.

Later, when a user schedules a perf event on this box, the event startup
routines execute blindly using this base:

intel_generic_uncore_msr_enable_event()
    wrmsrq(hwc->config_base, hwc->config);

Could this result in a fatal #GP fault by executing wrmsrq(0, ...), or
corrupt PCI configuration space by overwriting the Vendor or Device ID at
offset 0x0?

While this patch successfully prevents faults during boot or hotplug box
initialization, could it leave the crash accessible through user-controlled
perf execution?

>  		hwc->config_base = box_ctl + uncore_pci_event_ctl(box, hwc->idx);
>  		hwc->event_base  = box_ctl + uncore_pci_perf_ctr(box, hwc->idx);
>  		return true;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260527151154.130505-1-zide.chen@intel.com?part=2