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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.