linux-kernel - Re: [PATCH] KVM: arm64: Fix NULL pointer access issue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <450f11c2-6c11-4ffa-ae20-db4ea419a3ca@linaro.org>
Date: Mon, 1 Sep 2025 11:36:11 +0100
From: James Clark <james.clark@...aro.org>
To: Yingchao Deng <yingchao.deng@....qualcomm.com>
Cc: linux-arm-kernel@...ts.infradead.org, kvmarm@...ts.linux.dev,
 linux-kernel@...r.kernel.org, quic_yingdeng@...cinc.com,
 jinlong.mao@....qualcomm.com, tingwei.zhang@....qualcomm.com,
 Marc Zyngier <maz@...nel.org>, Oliver Upton <oliver.upton@...ux.dev>,
 Joey Gouly <joey.gouly@....com>, Suzuki K Poulose <suzuki.poulose@....com>,
 Zenghui Yu <yuzenghui@...wei.com>, Catalin Marinas
 <catalin.marinas@....com>, Will Deacon <will@...nel.org>
Subject: Re: [PATCH] KVM: arm64: Fix NULL pointer access issue



On 01/09/2025 11:01 am, 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.
> 
> Fixes: 054b88391bbe2 ("KVM: arm64: Support trace filtering for guests")
> Signed-off-by: Yingchao Deng <yingchao.deng@....qualcomm.com>
> ---
> Add a check to prevent accessing uninitialized per-CPU data.
> ---
>   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..add58056297293b4eb337028773b1b018ecc9d35 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()))
> +	    WARN_ON_ONCE(preemptible()) || !is_kvm_arm_initialised())

Hi Yingchao,

There shouldn't be a warning for this, at least for the case where it's 
not initialized and never will be. If you're never going to run a guest 
these functions can all skip, the same way for !has_vhe() etc.

A warning would only make sense if it's not initialized but will be in 
the future. I'm not sure if we need to worry about that though, because 
the KVM init stuff happens before the ETM driver is used.

Thanks
James

>   		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()))
> +	    WARN_ON_ONCE(preemptible()) || !is_kvm_arm_initialised())
>   		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() || WARN_ON_ONCE(preemptible()) ||
> +	    !is_kvm_arm_initialised())
>   		return;
>   
>   	if (has_vhe()) {
> 
> ---
> base-commit: 8cd53fb40a304576fa86ba985f3045d5c55b0ae3
> change-id: 20250901-etm_crash-0ee923eee98c
> 
> Best regards,