All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Akihiko Odaki" <odaki@rsg.ci.i.u-tokyo.ac.jp>
Cc: kvmarm@lists.linux.dev, "Oliver Upton" <oupton@kernel.org>,
	"Marc Zyngier" <maz@kernel.org>,
	kvm@vger.kernel.org
Subject: Re: [PATCH v9 12/16] KVM: arm64: PMU: Pass the pPMU to kvm_map_pmu_event()
Date: Mon, 20 Jul 2026 06:03:34 +0000	[thread overview]
Message-ID: <20260720060334.E9C6C1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260720-hybrid-v9-12-2b713ca1b5dc@rsg.ci.i.u-tokyo.ac.jp>

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

Pre-existing issues:
- [Critical] Host kernel panic via NULL pointer dereference in PMU event creation when a guest without a PMU toggles `MDCR_EL2.HPME`.
--

--- Patch [12]: [PATCH v9 12/16] KVM: arm64: PMU: Pass the pPMU to kvm_map_pmu_event() ---
commit 61c39cb093b2170b92839ae7097044db9d1474cc
Author: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>

KVM: arm64: PMU: Pass the pPMU to kvm_map_pmu_event()

This patch updates kvm_map_pmu_event() to accept the PMU structure directly
rather than implicitly looking it up via the VM argument. This prepares the
code to map events against a per-vCPU selected pPMU in the future.

> diff --git a/arch/arm64/kvm/pmu-emul.c b/arch/arm64/kvm/pmu-emul.c
> index c5c505b6fc61c..27db8877f96ea 100644
> --- a/arch/arm64/kvm/pmu-emul.c
> +++ b/arch/arm64/kvm/pmu-emul.c
[ ... ]
> @@ -725,7 +723,7 @@ static void kvm_pmu_create_perf_event(struct kvm_pmc *pmc)
>  	 * Don't create an event if we're running on hardware that requires
>  	 * PMUv3 event translation and we couldn't find a valid mapping.
>  	 */
> -	eventsel = kvm_map_pmu_event(vcpu->kvm, eventsel);
> +	eventsel = kvm_map_pmu_event(vcpu->kvm->arch.arm_pmu, eventsel);

[Severity: Critical]
This is a pre-existing issue, but this change makes it a bit more explicit.
Could this pass a NULL pointer to kvm_map_pmu_event() and cause a host kernel
panic?

If a guest with nested virtualization enabled but no PMU configured toggles
the MDCR_EL2.HPME bit, access_mdcr() will unconditionally trigger a
KVM_REQ_RELOAD_PMU request without checking if the VM actually has a PMU.

When kvm_vcpu_reload_pmu() handles this request on the next vCPU entry,
it tries to reprogram the cycle counter (which defaults to enabled). This
eventually reaches kvm_pmu_create_perf_event():

arch/arm64/kvm/sys_regs.c:access_mdcr() {
    ...
    kvm_pmu_handle_mdcr(vcpu, old, val); /* Triggers KVM_REQ_RELOAD_PMU */
}

arch/arm64/kvm/pmu-emul.c:kvm_pmu_create_perf_event() {
    ...
    eventsel = kvm_map_pmu_event(vcpu->kvm->arch.arm_pmu, eventsel);
}

arch/arm64/kvm/pmu-emul.c:kvm_map_pmu_event() {
    ...
    if (unlikely(pmu->map_pmuv3_event)) /* NULL pointer dereference */
}

Because no PMU was initialized for this guest, vcpu->kvm->arch.arm_pmu is NULL.

Could access_mdcr() or kvm_pmu_create_perf_event() check if the PMU is
actually initialized before attempting to create events?

>  	if (eventsel < 0)
>  		return;
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260720-hybrid-v9-0-2b713ca1b5dc@rsg.ci.i.u-tokyo.ac.jp?part=12

  reply	other threads:[~2026-07-20  6:03 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-20  5:37 [PATCH v9 00/16] KVM: arm64: PMU: Use multiple host PMUs Akihiko Odaki
2026-07-20  5:37 ` [PATCH v9 01/16] KVM: arm64: Serialize repeated vCPU initialization Akihiko Odaki
2026-07-20  5:37 ` [PATCH v9 02/16] KVM: arm64: PMU: Stop updating MDCR_EL2.HPMN Akihiko Odaki
2026-07-20  5:58   ` sashiko-bot
2026-07-20  5:37 ` [PATCH v9 03/16] KVM: arm64: PMU: Freeze counter count after first run Akihiko Odaki
2026-07-20  5:37 ` [PATCH v9 04/16] KVM: arm64: selftests: Test SET_NR_COUNTERS " Akihiko Odaki
2026-07-20  6:08   ` sashiko-bot
2026-07-20  5:37 ` [PATCH v9 05/16] KVM: arm64: PMU: Keep implemented counter mask EL-independent Akihiko Odaki
2026-07-20  5:53   ` sashiko-bot
2026-07-20  5:38 ` [PATCH v9 06/16] KVM: arm64: PMU: Recreate events after MDCR_EL2 changes Akihiko Odaki
2026-07-20  5:57   ` sashiko-bot
2026-07-20  5:38 ` [PATCH v9 07/16] tools headers: Use u* types for bitfield helpers Akihiko Odaki
2026-07-20  5:38 ` [PATCH v9 08/16] KVM: arm64: selftests: Cover PMU state in MDCR_EL2 Akihiko Odaki
2026-07-20  5:38 ` [PATCH v9 09/16] arm64: errata: Require Apple IMPDEF PMUv3 traps on all CPUs Akihiko Odaki
2026-07-20  6:01   ` sashiko-bot
2026-07-20  5:38 ` [PATCH v9 10/16] KVM: arm64: Don't clear vcpu->cpu in kvm_arch_vcpu_put() Akihiko Odaki
2026-07-20  5:38 ` [PATCH v9 11/16] KVM: arm64: PMU: Protect the list of PMUs with RCU Akihiko Odaki
2026-07-20  5:38 ` [PATCH v9 12/16] KVM: arm64: PMU: Pass the pPMU to kvm_map_pmu_event() Akihiko Odaki
2026-07-20  6:03   ` sashiko-bot [this message]
2026-07-20  5:38 ` [PATCH v9 13/16] KVM: arm64: PMU: Pass the target CPU to kvm_pmu_probe_armpmu() Akihiko Odaki
2026-07-20  5:38 ` [PATCH v9 14/16] KVM: arm64: PMU: Implement fixed-counters-only emulation Akihiko Odaki
2026-07-20  6:17   ` sashiko-bot
2026-07-20  5:38 ` [PATCH v9 15/16] KVM: arm64: PMU: Introduce FIXED_COUNTERS_ONLY Akihiko Odaki
2026-07-20  5:38 ` [PATCH v9 16/16] KVM: arm64: selftests: Test PMU_V3_FIXED_COUNTERS_ONLY Akihiko Odaki

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=20260720060334.E9C6C1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.linux.dev \
    --cc=maz@kernel.org \
    --cc=odaki@rsg.ci.i.u-tokyo.ac.jp \
    --cc=oupton@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.