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>,
	Christoffer Dall <christoffer.dall@arm.com>,
	Wei-Lin Chang <weilin.chang@arm.com>,
	Yao Yuan <yaoyuan@linux.alibaba.com>,
	linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
	linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH v2 0/2] KVM: arm64: Fix spurious warn, null ptr deref on S2 teardown race
Date: Mon, 24 Aug 2026 16:56:46 +0100	[thread overview]
Message-ID: <87ecfno6kh.wl-maz@kernel.org> (raw)
In-Reply-To: <aoxD4omq8gKYdFKL@gremlin>

On Mon, 24 Aug 2026 14:15:29 +0100,
"Lorenzo Stoakes (ARM)" <ljs@kernel.org> wrote:
> 
> On Sun, Aug 23, 2026 at 08:53:31AM +0100, Marc Zyngier wrote:
> > On Sat, 22 Aug 2026 18:46:52 +0100,
> > "Lorenzo Stoakes (ARM)" <ljs@kernel.org> wrote:
> > >
> > > When GFNs are invalidated in L0 an MMU notifier triggers
> > > kvm_unmap_gfn_range() which tears down all of the stage 2 shadow page
> > > tables for nested guests via kvm_nested_s2_unmap().
> > >
> > > To avoid lockup, the kvm->mmu_lock is dropped while doing this and the task
> > > rescheduled once for each block of physical address space (32 MiB for 16
> > > KiB page size), with the lock being reacquired once the task is scheduled
> > > again.
> > >
> > > This results in a potential race between this L0 tear down and tear down of
> > > the guest itself in kvm_flush_shadow_all(), a race which has been observed
> > > on real hardware.
> > >
> > > When this race occurs it causes an invalid kernel warning when the PGT of a
> > > nested MMU is cleared by kvm_flush_shadow_all() ->
> > > kvm_arch_flush_shadow_all() -> kvm_free_stage2_pgd().
> > >
> > > Patch 1 fixes this by having stage2_apply_range() no longer return an error
> > > when it has experienced a benign race with pgt teardown when it drops the
> > > lock.
> > >
> > > Patch 2 addresses something more serious - bad timing can turn this spurious
> > > warning into a NULL pointer dereference.
> > >
> > > kvm_arch_flush_shadow_all() calls kvm_uninit_stage2_mmu() which calls
> > > kvm_free_stage2_pgd() on the canonical kvm->arch.mmu for that guest's S2
> > > mappings, making it NULL.
> > >
> > > This is problematic if it happens before stage2_apply_range() reacquires
> > > the kvm->mmu_lock, as it ultimately returns to kvm_nested_s2_unmap() which
> > > dereferences kvm->arch.mmu.pgt with the mmu lock held under the incorrect
> > > assumption that it means it's valid, resulting in a NULL pointer
> > > dereference.
> > >
> > > Fix that by checking if kvm->arch.mmu.pgt is NULL before dereferencing it
> > > in kvm_nested_s2_unmap() and kvm_nested_s2_wp().
> >
> > With the commit message for patch #1 trimmed to something that fits on
> > a couple of standard terminal screens ;-) :
> 
> Haha sure will put it on a diet and respin :)

Oliver can probably do so when applying the series.

Thanks,

	M.

-- 
Jazz isn't dead. It just smells funny.

  reply	other threads:[~2026-08-24 15:54 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-22 17:46 [PATCH v2 0/2] KVM: arm64: Fix spurious warn, null ptr deref on S2 teardown race Lorenzo Stoakes (ARM)
2026-08-22 17:46 ` [PATCH v2 1/2] KVM: arm64: Fix spurious warning for benign stage 2 " Lorenzo Stoakes (ARM)
2026-08-22 18:02   ` sashiko-bot
2026-08-23  5:38   ` Yao Yuan
2026-08-24 13:29     ` Lorenzo Stoakes (ARM)
2026-08-22 17:46 ` [PATCH v2 2/2] KVM: arm64: nv: Fix null ptr deref on nested wp/unmap, " Lorenzo Stoakes (ARM)
2026-08-22 18:05   ` sashiko-bot
2026-08-23  7:53 ` [PATCH v2 0/2] KVM: arm64: Fix spurious warn, null ptr deref on S2 " Marc Zyngier
2026-08-24 13:15   ` Lorenzo Stoakes (ARM)
2026-08-24 15:56     ` Marc Zyngier [this message]
2026-08-24 17:34       ` 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=87ecfno6kh.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=christoffer.dall@arm.com \
    --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=weilin.chang@arm.com \
    --cc=will@kernel.org \
    --cc=yaoyuan@linux.alibaba.com \
    --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.