All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
Cc: Oliver Upton <oupton@kernel.org>, Fuad Tabba <tabba@google.com>,
	Joey Gouly <joey.gouly@arm.com>,
	Steffen Eiden <seiden@linux.ibm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Zenghui Yu <yuzenghui@huawei.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Jintack Lim <jintack.lim@linaro.org>,
	Christoffer Dall <christoffer.dall@linaro.org>,
	Christoffer Dall <christoffer.dall@arm.com>,
	linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
	linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH 2/2] KVM: arm64: nv: Fix null ptr deref in kvm_nested_s2_unmap() on S2 teardown
Date: Sat, 22 Aug 2026 08:32:04 +0100	[thread overview]
Message-ID: <86y0dy4nm3.wl-maz@kernel.org> (raw)
In-Reply-To: <20260812-kvm-arm-nested-virt-fix-v1-2-4ad883f1b6a5@kernel.org>

On Wed, 12 Aug 2026 14:31:21 +0100,
"Lorenzo Stoakes (ARM)" <ljs@kernel.org> wrote:
> 
> Commit 7270cc9157f4 ("KVM: arm64: nv: Handle VNCR_EL2 invalidation from MMU
> notifiers") introduced VNCR_EL2 invalidation in kvm_nested_s2_unmap().
> 
> However at the point of this being performed concurrent stage 2 teardown of
> a nested guest can cause kvm->arch.mmu.pgt to be set to NULL.
> 
> This happens in kvm_flush_shadow_all() -> kvm_arch_flush_shadow_all() ->
> kvm_free_stage2_pgd() and is performed under the kvm->mmu_lock.
> 
> Commit ec14c272408a ("KVM: arm64: nv: Unmap/flush shadow stage 2 page
> tables") introduced the teardown of the entire nested MMU range, which then
> invokes stage2_apply_range() with resched=true:
> 
> mmu_notifier_invalidate_range_start()
>   -> ... -> kvm_mmu_notifier_invalidate_range_start()
>     -> kvm_mmu_unmap_gfn_range()
>       -> kvm_unmap_gfn_range()
>         -> kvm_nested_s2_unmap()
>           -> kvm_stage2_unmap_range()
>             -> __unmap_stage2_range()
>                 -> stage2_apply_range()
> 
> This means that stage2_apply_range() can drop the kvm->mmu_lock and thus
> concurrent progress can be made in lockstep with
> kvm_arch_flush_shadow_all().
> 
> If kvm_arch_flush_shadow_all() advances ahead of stage2_apply_range() and
> completes its operation it guarantees a NULL pointer deref.
> 
> Since kvm_free_stage2_pgd() is performed under the kvm->mmu_lock this will
> either be observed NULL or not and serialised against
> kvm_free_stage2_pgd().
> 
> Resolve the issue by explicitly checking for a NULL value. Since this
> shouldn't be possible if blocking is not allowed, raise a warning if it is
> ever NULL in this case.
> 
> Fixes: 7270cc9157f4 ("KVM: arm64: nv: Handle VNCR_EL2 invalidation from MMU notifiers")
> Cc: stable@vger.kernel.org
> Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
> ---
>  arch/arm64/kvm/nested.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
> index 17123f0b6dab..9fc0b1696dcb 100644
> --- a/arch/arm64/kvm/nested.c
> +++ b/arch/arm64/kvm/nested.c
> @@ -1295,7 +1295,11 @@ void kvm_nested_s2_unmap(struct kvm *kvm, bool may_block)
>  			kvm_stage2_unmap_range(mmu, 0, kvm_phys_size(mmu), may_block);
>  	}
>  
> -	kvm_invalidate_vncr_ipa(kvm, 0, BIT(kvm->arch.mmu.pgt->ia_bits));
> +	/* NULL pgt should only be possible if raced when mmu_lock dropped. */
> +	if (kvm->arch.mmu.pgt)
> +		kvm_invalidate_vncr_ipa(kvm, 0, BIT(kvm->arch.mmu.pgt->ia_bits));
> +	else
> +		WARN_ON(!may_block);

I don't think the WARN_ON() should be here. We already have one at the
iterator level, which will fire in the same conditions.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.


  parent reply	other threads:[~2026-08-22  7:32 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-12 13:31 [PATCH 0/2] KVM: arm64: Fix spurious warn, null ptr deref on S2 teardown race Lorenzo Stoakes (ARM)
2026-08-12 13:31 ` [PATCH 1/2] KVM: arm64: Fix spurious warning for benign stage 2 " Lorenzo Stoakes (ARM)
2026-08-12 13:46   ` Lorenzo Stoakes (ARM)
2026-08-12 13:54   ` sashiko-bot
2026-08-13 15:35     ` Lorenzo Stoakes (ARM)
2026-08-12 23:20   ` Wei-Lin Chang
2026-08-13 15:24     ` Lorenzo Stoakes (ARM)
2026-08-14  7:18       ` Yao Yuan
2026-08-14  8:48         ` Lorenzo Stoakes (ARM)
2026-08-17  0:38           ` Yao Yuan
2026-08-17  7:46             ` Lorenzo Stoakes (ARM)
2026-08-12 13:31 ` [PATCH 2/2] KVM: arm64: nv: Fix null ptr deref in kvm_nested_s2_unmap() on S2 teardown Lorenzo Stoakes (ARM)
2026-08-12 14:01   ` sashiko-bot
2026-08-13 15:56     ` Lorenzo Stoakes (ARM)
2026-08-22  7:28       ` Marc Zyngier
2026-08-22 14:27         ` Lorenzo Stoakes (ARM)
2026-08-22  7:32   ` Marc Zyngier [this message]
2026-08-22 14:26     ` Lorenzo Stoakes (ARM)

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=86y0dy4nm3.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=christoffer.dall@arm.com \
    --cc=christoffer.dall@linaro.org \
    --cc=jintack.lim@linaro.org \
    --cc=joey.gouly@arm.com \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ljs@kernel.org \
    --cc=oupton@kernel.org \
    --cc=seiden@linux.ibm.com \
    --cc=stable@vger.kernel.org \
    --cc=suzuki.poulose@arm.com \
    --cc=tabba@google.com \
    --cc=will@kernel.org \
    --cc=yuzenghui@huawei.com \
    /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.