[PATCH v2] KVM: arm64: Fix NULL pointer access issue

[PATCH v2] KVM: arm64: Fix NULL pointer access issue

[Yingchao Deng]

When linux is booted in EL1, macro "host_data_ptr()" is a wrapper that
resolves to "&per_cpu_ptr_nvhe_sym(kvm_host_data, cpu)",
is_hyp_mode_available() return false during kvm_arm_init, the per-CPU base
pointer __kvm_nvhe_kvm_arm_hyp_percpu_base[cpu] remains uninitialized.
Consequently, any access via per_cpu_ptr_nvhe_sym(kvm_host_data, cpu)
will result in a NULL pointer.

Add is_kvm_arm_initialised() condition check to ensure that kvm_arm_init
completes all necessary initialization steps, including init_hyp_mode.

Fixes: 054b88391bbe2 ("KVM: arm64: Support trace filtering for guests")
Signed-off-by: Yingchao Deng <yingchao.deng@oss.qualcomm.com>
Reviewed-by: James Clark <james.clark@linaro.org>
---
Add a check to prevent accessing uninitialized per-CPU data.
---
Changes in v2:
1. Move the warning to the end in order to improve readability. No
functional change intended
- Link to v1: https://lore.kernel.org/r/20250901-etm_crash-v1-1-ce65e44c137c@oss.qualcomm.com
---
 arch/arm64/kvm/debug.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c
index 381382c19fe4741980c79b08bbdab6a1bcd825ad..593fcbbc7c014335c5999b774f9bfa367e709cb5 100644
--- a/arch/arm64/kvm/debug.c
+++ b/arch/arm64/kvm/debug.c
@@ -233,7 +233,7 @@ void kvm_debug_handle_oslar(struct kvm_vcpu *vcpu, u64 val)
 void kvm_enable_trbe(void)
 {
 	if (has_vhe() || is_protected_kvm_enabled() ||
-	    WARN_ON_ONCE(preemptible()))
+	    !is_kvm_arm_initialised() || WARN_ON_ONCE(preemptible()))
 		return;
 
 	host_data_set_flag(TRBE_ENABLED);
@@ -243,7 +243,7 @@ EXPORT_SYMBOL_GPL(kvm_enable_trbe);
 void kvm_disable_trbe(void)
 {
 	if (has_vhe() || is_protected_kvm_enabled() ||
-	    WARN_ON_ONCE(preemptible()))
+	    !is_kvm_arm_initialised() || WARN_ON_ONCE(preemptible()))
 		return;
 
 	host_data_clear_flag(TRBE_ENABLED);
@@ -252,7 +252,8 @@ EXPORT_SYMBOL_GPL(kvm_disable_trbe);
 
 void kvm_tracing_set_el1_configuration(u64 trfcr_while_in_guest)
 {
-	if (is_protected_kvm_enabled() || WARN_ON_ONCE(preemptible()))
+	if (is_protected_kvm_enabled() || !is_kvm_arm_initialised() ||
+	    WARN_ON_ONCE(preemptible()))
 		return;
 
 	if (has_vhe()) {

---
base-commit: 8cd53fb40a304576fa86ba985f3045d5c55b0ae3
change-id: 20250901-etm_crash-0ee923eee98c

Best regards,
-- 
Yingchao Deng <yingchao.deng@oss.qualcomm.com>

Re: [PATCH v2] KVM: arm64: Fix NULL pointer access issue

[Oliver Upton]

Hi Yingchao,

The shortlog is extremely vague, you should aim to succinctly describe
the functional change of your patch. e.g.

  KVM: arm64: Return early from trace helpers when KVM isn't available

On Tue, Sep 02, 2025 at 11:48:25AM +0800, Yingchao Deng wrote:
> When linux is booted in EL1, macro "host_data_ptr()" is a wrapper that
> resolves to "&per_cpu_ptr_nvhe_sym(kvm_host_data, cpu)",
> is_hyp_mode_available() return false during kvm_arm_init, the per-CPU base
> pointer __kvm_nvhe_kvm_arm_hyp_percpu_base[cpu] remains uninitialized.
> Consequently, any access via per_cpu_ptr_nvhe_sym(kvm_host_data, cpu)
> will result in a NULL pointer.
> 
> Add is_kvm_arm_initialised() condition check to ensure that kvm_arm_init
> completes all necessary initialization steps, including init_hyp_mode.

OTOH, the changelog is very mechanical and hard to grok.

  When linux is booted at EL1, host_data_ptr() resolves to the nVHE
  hypervisor's copy of host data. When hyp mode isn't available for
  KVM the nVHE percpu bases remain uninitialized. Consequently, any usage
  of host_data_ptr() will result in a NULL dereference which has been
  observed in KVM's trace filtering helpers.

  Add an early return to the trace filtering helpers if KVM isn't
  initialized, avoiding the NULL dereference.

> Fixes: 054b88391bbe2 ("KVM: arm64: Support trace filtering for guests")
> Signed-off-by: Yingchao Deng <yingchao.deng@oss.qualcomm.com>
> Reviewed-by: James Clark <james.clark@linaro.org>
> ---
> Add a check to prevent accessing uninitialized per-CPU data.
> ---
> Changes in v2:
> 1. Move the warning to the end in order to improve readability. No
> functional change intended

IMO, the warning should be the very first condition we evaluate. Even if
the system configuration leads to an early return anyway (e.g. protected
mode) the caller is not invoking these helpers from the right context.

Thanks,
Oliver