Re: [PATCH 1/2] perf/x86/intel: Clear stale ACR mask before updating new mask

[sashiko-bot@kernel.org]

Sashiko AI review found 2 potential issue(s):
- [High] Incomplete Fix: Early return bypasses the newly added stale mask cleanup for subsequent events.
- [High] Missing bounds check on user-provided mask allows cross-event PMU interference (cross-wiring).
--

commit f516548e46c9feac44792cd958b5c0a840d60d43
Author: Dapeng Mi <dapeng1.mi@linux.intel.com>

perf/x86/intel: Clear stale ACR mask before updating new mask

This commit clears the ACR mask before applying a new one to prevent
stale bits from persisting during event rescheduling. It ensures the
hardware state does not get polluted by previous configurations.

> diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
> index 4768236c054bb..58c236ce47474 100644
> --- a/arch/x86/events/intel/core.c
> +++ b/arch/x86/events/intel/core.c
> @@ -3344,6 +3344,9 @@ static void intel_pmu_acr_late_setup(struct cpu_hw_events *cpuc)
>  			event = cpuc->event_list[j];
>  			if (event->group_leader != leader->group_leader)
>  				break;
> +
> +			/* Clear stale ACR mask first. */
> +			event->hw.config1 = 0;
>  			for_each_set_bit(idx, (unsigned long *)&event->attr.config2, X86_PMC_IDX_MAX) {
>  				if (i + idx >= cpuc->n_events ||
>  				    !is_acr_event_group(cpuc->event_list[i + idx]))

Could this validation check allow unprivileged users to cross-wire the PMU?

Since is_acr_event_group() only verifies that the target event belongs to any
ACR group, rather than the same group_leader, does this allow a user-provided
out-of-bounds bit in config2 to point to an independent, system-wide ACR event
running on the same CPU?

If so, it seems the hardware counter index of an unrelated privileged event
could be blindly copied into the user's hw.config1.

>  					return;

Does this early return bypass the newly added stale mask cleanup for subsequent
events?

Because attr.config2 is user-controlled, a user could supply a malformed mask
with an out-of-bounds bit to intentionally trigger this early return.

Since it returns from intel_pmu_acr_late_setup() completely, wouldn't this skip
the event->hw.config1 = 0 cleanup for all subsequent ACR events scheduled on the
same CPU, leaving them with a polluted hardware state?

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