From: sashiko-bot@kernel.org
To: "Dapeng Mi" <dapeng1.mi@linux.intel.com>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [Patch v3 1/8] perf/x86: Unregister PMI handler on PMU init failure
Date: Fri, 17 Jul 2026 08:33:09 +0000 [thread overview]
Message-ID: <20260717083310.79B551F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260717080342.1879573-2-dapeng1.mi@linux.intel.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Pre-existing Use-After-Free window for `cpuc->pmu` if `perf_pmu_register()` fails on hybrid systems.
--
--- Patch [1]: [Patch v3 1/8] perf/x86: Unregister PMI handler on PMU init failure ---
commit 841a0ed2adb8a95774faf3b5508e90fdd97d9135
Author: Dapeng Mi <dapeng1.mi@linux.intel.com>
perf/x86: Unregister PMI handler on PMU init failure
This commit fixes an NMI handler leak in init_hw_perf_events() by unregistering
the NMI handler when PMU initialization fails before clearing the x86_pmu state.
> diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
> index af0b67ffb43d8..872d07a5fa80d 100644
> --- a/arch/x86/events/core.c
> +++ b/arch/x86/events/core.c
[ ... ]
> @@ -2273,6 +2273,8 @@ static int __init init_hw_perf_events(void)
> cpuhp_remove_state(CPUHP_AP_PERF_X86_STARTING);
> out:
> cpuhp_remove_state(CPUHP_PERF_X86_PREPARE);
> +pmi_unregister:
> + unregister_nmi_handler(NMI_LOCAL, "PMI");
> out_bad_pmu:
[Severity: High]
This is a pre-existing issue, but does this error path leave a dangling
pointer that could lead to a Use-After-Free?
On hybrid systems, if perf_pmu_register() fails, the error path frees the
x86_pmu.hybrid_pmu structures. However, CPUHP_AP_PERF_X86_STARTING was already
set up, so cpuc->pmu on all online CPUs was initialized to point to these
now-freed structures.
The CPU hotplug state rollback doesn't set cpuc->pmu back to NULL. Since
x86_pmu_static_call_update() has already routed x86_pmu_guest_get_msrs to
intel_guest_get_msrs(), and the perf_is_hybrid static key remains enabled,
could a subsequent KVM guest launch trigger a UAF?
When KVM calls perf_guest_get_msrs(), it jumps to intel_guest_get_msrs(),
which unconditionally dereferences the dangling cpuc->pmu pointer:
arch/x86/events/intel/core.c:intel_guest_get_msrs() {
...
u64 intel_ctrl = hybrid(cpuc->pmu, intel_ctrl);
...
}
> memset(&x86_pmu, 0, sizeof(x86_pmu));
> return err;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260717080342.1879573-1-dapeng1.mi@linux.intel.com?part=1
next prev parent reply other threads:[~2026-07-17 8:33 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-17 8:03 [Patch v3 0/8] perf/x86: Miscellaneous PMU bug fixes and optimizations Dapeng Mi
2026-07-17 8:03 ` [Patch v3 1/8] perf/x86: Unregister PMI handler on PMU init failure Dapeng Mi
2026-07-17 8:33 ` sashiko-bot [this message]
2026-07-17 8:03 ` [Patch v3 2/8] perf/x86: Free hybrid state " Dapeng Mi
2026-07-17 8:03 ` [Patch v3 3/8] perf/x86: Guard intel_pmu_cpu_dead() against invalid hybrid PMU casts Dapeng Mi
2026-07-17 9:31 ` sashiko-bot
2026-07-17 8:03 ` [Patch v3 4/8] perf/x86/intel: Unwind cpuc state if PEBS buffer setup fails Dapeng Mi
2026-07-17 8:03 ` [Patch v3 5/8] perf/x86: Remove stale fixed counter helper and fix hybrid PMU access Dapeng Mi
2026-07-17 8:03 ` [Patch v3 6/8] perf/x86/intel: Fix intel_cap handling on hybrid PMUs Dapeng Mi
2026-07-17 8:03 ` [Patch v3 7/8] perf/x86: Optimize ACR handling in match_prev_assignment() Dapeng Mi
2026-07-17 8:03 ` [Patch v3 8/8] perf/x86/intel: Prevent drain_pebs() reentry Dapeng Mi
2026-07-17 10:38 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260717083310.79B551F00A3A@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dapeng1.mi@linux.intel.com \
--cc=linux-perf-users@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox