* [PATCH v4] KVM: arm64: nv: Keep the shadow S2 MMUs at fixed addresses
@ 2026-08-07 19:59 Karl Mehltretter
2026-08-07 20:17 ` sashiko-bot
0 siblings, 1 reply; 3+ messages in thread
From: Karl Mehltretter @ 2026-08-07 19:59 UTC (permalink / raw)
To: Marc Zyngier, Oliver Upton
Cc: Karl Mehltretter, Fuad Tabba, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
linux-arm-kernel, kvmarm, linux-kernel, stable, grayhat
kvm_vcpu_init_nested() can grow kvm->arch.nested_mmus while initialising
another vCPU: it copies the MMUs, publishes the new allocation, and frees
the old one. It updates pgt->mmu back-pointers, but not hw_mmu, leaving
already-running vCPUs with pointers to freed memory. hw_mmu cannot be
fixed up the same way: a running vCPU reads it without holding mmu_lock.
The nested S2 ptdump file's debugfs private data is also affected, as it
points into the freed array.
KASAN reports an access through the stale hw_mmu pointer as a
slab-use-after-free in kvm_handle_guest_abort().
Turn nested_mmus into a pointer table allocated once for the maximum
number of vCPUs during VM creation. Allocate the MMUs separately as
vCPUs are initialised and append their pointers to that table. The MMU
objects never move, so cached hw_mmu pointers, pgt->mmu back-pointers,
and ptdump private data remain valid.
Two issues in the old implementation are also fixed:
- The old failure path passed uninitialised MMUs to
kvm_free_stage2_pgd(), which derives kvm from mmu->arch and can
therefore dereference an invalid pointer. Only call
kvm_free_stage2_pgd() for initialised MMUs.
- Previously, initialisation of the new MMUs was not ordered before
publication of nested_mmus_size. Fix this by taking mmu_lock when
increasing nested_mmus_size.
Fixes: 4f128f8e1aaa ("KVM: arm64: nv: Support multiple nested Stage-2 mmu structures")
Cc: stable@vger.kernel.org
Suggested-by: Marc Zyngier <maz@kernel.org>
Assisted-by: Claude:claude-fable-5
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
---
Changes in v4:
- The code diff changes only arch/arm64/kvm/nested.c compared to v3:
- Restore v2's centralized error paths (Wei-Lin Chang).
- Restore explicit write_lock()/write_unlock() to avoid mixing goto-based
error handling with cleanup guards.
- Drop the allocation-failure comment (Marc Zyngier).
v3: https://lore.kernel.org/r/20260806192451.10169-1-kmehltretter@gmail.com/
Changes in v3:
- Tighten the commit message (Wei-Lin Chang).
- The code diff changes only arch/arm64/kvm/nested.c compared to v2:
- Drop the redundant pointer-table allocation comment and use
guard(write_lock) when publishing nested_mmus_size (Wei-Lin Chang).
- Rewrite the error handling without gotos.
v2: https://lore.kernel.org/r/20260806062352.93489-1-kmehltretter@gmail.com/
Changes in v2:
- Allocate the fixed pointer table during VM creation, as suggested by Marc.
- Allocate the MMUs individually and simplify the error and teardown paths.
- Drop the selftest patch that triggered KASAN.
It is not a good fit for the existing suite.
v1: https://lore.kernel.org/r/20260803224405.41468-1-kmehltretter@gmail.com/
arch/arm64/include/asm/kvm_host.h | 6 +-
arch/arm64/include/asm/kvm_nested.h | 2 +-
arch/arm64/kvm/arm.c | 7 ++-
arch/arm64/kvm/nested.c | 95 ++++++++++++++++-------------
4 files changed, 60 insertions(+), 50 deletions(-)
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index bae2c4f92ef5..59d1d77ee116 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -319,10 +319,10 @@ struct kvm_arch {
u64 fgu[__NR_FGT_GROUP_IDS__];
/*
- * Stage 2 paging state for VMs with nested S2 using a virtual
- * VMID.
+ * Stage 2 paging state for VMs with nested S2 using a virtual VMID.
+ * MMUs are allocated separately to keep their addresses stable.
*/
- struct kvm_s2_mmu *nested_mmus;
+ struct kvm_s2_mmu **nested_mmus;
size_t nested_mmus_size;
int nested_mmus_next;
diff --git a/arch/arm64/include/asm/kvm_nested.h b/arch/arm64/include/asm/kvm_nested.h
index 012d711034d1..d21be647ac57 100644
--- a/arch/arm64/include/asm/kvm_nested.h
+++ b/arch/arm64/include/asm/kvm_nested.h
@@ -66,7 +66,7 @@ static inline u64 translate_ttbr0_el2_to_ttbr0_el1(u64 ttbr0)
extern bool forward_smc_trap(struct kvm_vcpu *vcpu);
extern bool forward_debug_exception(struct kvm_vcpu *vcpu);
-extern void kvm_init_nested(struct kvm *kvm);
+extern int kvm_init_nested(struct kvm *kvm);
extern int kvm_vcpu_init_nested(struct kvm_vcpu *vcpu);
extern void kvm_init_nested_s2_mmu(struct kvm_s2_mmu *mmu);
extern struct kvm_s2_mmu *lookup_s2_mmu(struct kvm_vcpu *vcpu);
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 50adfff75be8..e883e45382fb 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -223,8 +223,6 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
mutex_unlock(&kvm->lock);
#endif
- kvm_init_nested(kvm);
-
ret = kvm_share_hyp(kvm, kvm + 1);
if (ret)
return ret;
@@ -239,6 +237,10 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
if (ret)
goto err_free_cpumask;
+ ret = kvm_init_nested(kvm);
+ if (ret)
+ goto err_uninit_mmu;
+
if (is_protected_kvm_enabled()) {
/*
* If any failures occur after this is successful, make sure to
@@ -267,6 +269,7 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
err_uninit_mmu:
kvm_uninit_stage2_mmu(kvm);
+ kvfree(kvm->arch.nested_mmus);
err_free_cpumask:
free_cpumask_var(kvm->arch.supported_cpus);
err_unshare_kvm:
diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
index dfb96edbdc43..8376adbb8736 100644
--- a/arch/arm64/kvm/nested.c
+++ b/arch/arm64/kvm/nested.c
@@ -44,11 +44,18 @@ struct vncr_tlb {
*/
#define S2_MMU_PER_VCPU 2
-void kvm_init_nested(struct kvm *kvm)
+int kvm_init_nested(struct kvm *kvm)
{
- kvm->arch.nested_mmus = NULL;
+ kvm->arch.nested_mmus = kvcalloc(KVM_MAX_VCPUS * S2_MMU_PER_VCPU,
+ sizeof(*kvm->arch.nested_mmus),
+ GFP_KERNEL_ACCOUNT);
+ if (!kvm->arch.nested_mmus)
+ return -ENOMEM;
+
kvm->arch.nested_mmus_size = 0;
atomic_set(&kvm->arch.vncr_map_count, 0);
+
+ return 0;
}
static int init_nested_s2_mmu(struct kvm *kvm, struct kvm_s2_mmu *mmu)
@@ -66,11 +73,17 @@ static int init_nested_s2_mmu(struct kvm *kvm, struct kvm_s2_mmu *mmu)
return kvm_init_stage2_mmu(kvm, mmu, kvm_get_pa_bits(kvm));
}
+static void free_nested_s2_mmu(struct kvm_s2_mmu *mmu)
+{
+ kvm_free_stage2_pgd(mmu);
+ kfree(mmu);
+}
+
int kvm_vcpu_init_nested(struct kvm_vcpu *vcpu)
{
struct kvm *kvm = vcpu->kvm;
- struct kvm_s2_mmu *tmp;
- int num_mmus, ret = 0;
+ struct kvm_s2_mmu *mmu;
+ int num_mmus, ret, i;
if (test_bit(KVM_ARM_VCPU_HAS_EL2_E2H0, kvm->arch.vcpu_features) &&
!cpus_have_final_cap(ARM64_HAS_HCR_NV1))
@@ -83,52 +96,46 @@ int kvm_vcpu_init_nested(struct kvm_vcpu *vcpu)
if (!vcpu->arch.ctxt.vncr_array)
return -ENOMEM;
- /*
- * Let's treat memory allocation failures as benign: If we fail to
- * allocate anything, return an error and keep the allocated array
- * alive. Userspace may try to recover by initializing the vcpu
- * again, and there is no reason to affect the whole VM for this.
- */
num_mmus = atomic_read(&kvm->online_vcpus) * S2_MMU_PER_VCPU;
- if (num_mmus > kvm->arch.nested_mmus_size) {
- tmp = kvcalloc(num_mmus, sizeof(*tmp), GFP_KERNEL_ACCOUNT);
- if (!tmp)
- return -ENOMEM;
-
- write_lock(&kvm->mmu_lock);
+ if (num_mmus <= kvm->arch.nested_mmus_size)
+ return 0;
- if (kvm->arch.nested_mmus_size) {
- memcpy(tmp, kvm->arch.nested_mmus,
- size_mul(sizeof(*tmp), kvm->arch.nested_mmus_size));
+ lockdep_assert_held(&kvm->arch.config_lock);
- for (int i = 0; i < kvm->arch.nested_mmus_size; i++)
- tmp[i].pgt->mmu = &tmp[i];
+ for (i = 0; i < S2_MMU_PER_VCPU; i++) {
+ mmu = kzalloc_obj(*mmu, GFP_KERNEL_ACCOUNT);
+ if (!mmu) {
+ ret = -ENOMEM;
+ goto err_free_mmus;
}
- swap(kvm->arch.nested_mmus, tmp);
-
- write_unlock(&kvm->mmu_lock);
+ ret = init_nested_s2_mmu(kvm, mmu);
+ if (ret) {
+ kfree(mmu);
+ goto err_free_vncr;
+ }
- kvfree(tmp);
+ kvm->arch.nested_mmus[kvm->arch.nested_mmus_size + i] = mmu;
}
- for (int i = kvm->arch.nested_mmus_size; !ret && i < num_mmus; i++)
- ret = init_nested_s2_mmu(kvm, &kvm->arch.nested_mmus[i]);
+ write_lock(&kvm->mmu_lock);
+
+ kvm->arch.nested_mmus_size += S2_MMU_PER_VCPU;
- if (ret) {
- for (int i = kvm->arch.nested_mmus_size; i < num_mmus; i++)
- kvm_free_stage2_pgd(&kvm->arch.nested_mmus[i]);
+ write_unlock(&kvm->mmu_lock);
- free_page((unsigned long)vcpu->arch.ctxt.vncr_array);
- vcpu->arch.ctxt.vncr_array = NULL;
+ return 0;
- return ret;
- }
+err_free_vncr:
+ free_page((unsigned long)vcpu->arch.ctxt.vncr_array);
+ vcpu->arch.ctxt.vncr_array = NULL;
- kvm->arch.nested_mmus_size = num_mmus;
+err_free_mmus:
+ while (i--)
+ free_nested_s2_mmu(kvm->arch.nested_mmus[kvm->arch.nested_mmus_size + i]);
- return 0;
+ return ret;
}
struct s2_walk_info {
@@ -725,7 +732,7 @@ void kvm_s2_mmu_iterate_by_vmid(struct kvm *kvm, u16 vmid,
write_lock(&kvm->mmu_lock);
for (int i = 0; i < kvm->arch.nested_mmus_size; i++) {
- struct kvm_s2_mmu *mmu = &kvm->arch.nested_mmus[i];
+ struct kvm_s2_mmu *mmu = kvm->arch.nested_mmus[i];
if (!kvm_s2_mmu_valid(mmu))
continue;
@@ -767,7 +774,7 @@ struct kvm_s2_mmu *lookup_s2_mmu(struct kvm_vcpu *vcpu)
* if S2 translation is disabled.
*/
for (int i = 0; i < kvm->arch.nested_mmus_size; i++) {
- struct kvm_s2_mmu *mmu = &kvm->arch.nested_mmus[i];
+ struct kvm_s2_mmu *mmu = kvm->arch.nested_mmus[i];
if (!kvm_s2_mmu_valid(mmu))
continue;
@@ -806,7 +813,7 @@ static struct kvm_s2_mmu *get_s2_mmu_nested(struct kvm_vcpu *vcpu)
for (i = kvm->arch.nested_mmus_next;
i < (kvm->arch.nested_mmus_size + kvm->arch.nested_mmus_next);
i++) {
- s2_mmu = &kvm->arch.nested_mmus[i % kvm->arch.nested_mmus_size];
+ s2_mmu = kvm->arch.nested_mmus[i % kvm->arch.nested_mmus_size];
if (atomic_read(&s2_mmu->refcnt) == 0)
break;
@@ -1223,7 +1230,7 @@ void kvm_nested_s2_wp(struct kvm *kvm)
return;
for (i = 0; i < kvm->arch.nested_mmus_size; i++) {
- struct kvm_s2_mmu *mmu = &kvm->arch.nested_mmus[i];
+ struct kvm_s2_mmu *mmu = kvm->arch.nested_mmus[i];
if (kvm_s2_mmu_valid(mmu))
kvm_stage2_wp_range(mmu, 0, kvm_phys_size(mmu));
@@ -1242,7 +1249,7 @@ void kvm_nested_s2_unmap(struct kvm *kvm, bool may_block)
return;
for (i = 0; i < kvm->arch.nested_mmus_size; i++) {
- struct kvm_s2_mmu *mmu = &kvm->arch.nested_mmus[i];
+ struct kvm_s2_mmu *mmu = kvm->arch.nested_mmus[i];
if (kvm_s2_mmu_valid(mmu))
kvm_stage2_unmap_range(mmu, 0, kvm_phys_size(mmu), may_block);
@@ -1261,7 +1268,7 @@ void kvm_nested_s2_flush(struct kvm *kvm)
return;
for (i = 0; i < kvm->arch.nested_mmus_size; i++) {
- struct kvm_s2_mmu *mmu = &kvm->arch.nested_mmus[i];
+ struct kvm_s2_mmu *mmu = kvm->arch.nested_mmus[i];
if (kvm_s2_mmu_valid(mmu))
kvm_stage2_flush_range(mmu, 0, kvm_phys_size(mmu));
@@ -1273,10 +1280,10 @@ void kvm_arch_flush_shadow_all(struct kvm *kvm)
int i;
for (i = 0; i < kvm->arch.nested_mmus_size; i++) {
- struct kvm_s2_mmu *mmu = &kvm->arch.nested_mmus[i];
+ struct kvm_s2_mmu *mmu = kvm->arch.nested_mmus[i];
if (!WARN_ON(atomic_read(&mmu->refcnt)))
- kvm_free_stage2_pgd(mmu);
+ free_nested_s2_mmu(mmu);
}
kvfree(kvm->arch.nested_mmus);
kvm->arch.nested_mmus = NULL;
--
2.39.5 (Apple Git-154)
^ permalink raw reply related [flat|nested] 3+ messages in thread* Re: [PATCH v4] KVM: arm64: nv: Keep the shadow S2 MMUs at fixed addresses
2026-08-07 19:59 [PATCH v4] KVM: arm64: nv: Keep the shadow S2 MMUs at fixed addresses Karl Mehltretter
@ 2026-08-07 20:17 ` sashiko-bot
2026-08-08 0:06 ` Karl Mehltretter
0 siblings, 1 reply; 3+ messages in thread
From: sashiko-bot @ 2026-08-07 20:17 UTC (permalink / raw)
To: Karl Mehltretter; +Cc: kvmarm, Oliver Upton, Marc Zyngier
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [Medium] The `kvm->arch.nested_mmus` array is leaked if VM creation fails after `kvm_arch_init_vm()` completes successfully.
Pre-existing issues:
- [High] If `kvm->arch.nested_mmus_size` is 0 or `nested_mmus` is freed, a nested stage-2 fault causes a host kernel panic in `get_s2_mmu_nested()` due to a race condition with `kvm_arch_flush_shadow_all()`.
--
--- Patch [1]: [PATCH v4] KVM: arm64: nv: Keep the shadow S2 MMUs at fixed addresses ---
commit 46aa9c715387bbae64560eea52655690ecd90bb6
Author: Karl Mehltretter <kmehltretter@gmail.com>
Subject: KVM: arm64: nv: Keep the shadow S2 MMUs at fixed addresses
This commit turns nested_mmus into a pointer table allocated once during VM
creation. The MMUs are allocated separately as VCPUs are initialized to keep
their addresses stable, fixing a slab-use-after-free issue.
> diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
> index fb54f6dad995c..3c9b5c5b02d1f 100644
> --- a/arch/arm64/kvm/nested.c
> +++ b/arch/arm64/kvm/nested.c
> @@ -43,11 +43,18 @@ struct vncr_tlb {
> */
> #define S2_MMU_PER_VCPU 2
>
> -void kvm_init_nested(struct kvm *kvm)
> +int kvm_init_nested(struct kvm *kvm)
> {
> - kvm->arch.nested_mmus = NULL;
> + kvm->arch.nested_mmus = kvcalloc(KVM_MAX_VCPUS * S2_MMU_PER_VCPU,
> + sizeof(*kvm->arch.nested_mmus),
> + GFP_KERNEL_ACCOUNT);
> + if (!kvm->arch.nested_mmus)
> + return -ENOMEM;
> +
[Severity: Medium]
Does this allocation leak if VM creation fails later in the process?
During kvm_create_vm(), kvm_arch_init_vm() calls kvm_init_nested() which
allocates kvm->arch.nested_mmus. If a subsequent initialization step in
kvm_create_vm() fails (e.g., hardware_enable_all() or
kvm_init_mmu_notifier()), the error path bypasses mmu_notifier_unregister()
and directly calls kvm_arch_destroy_vm().
Since kvm_arch_destroy_vm() on ARM64 does not free kvm->arch.nested_mmus,
could the array be permanently leaked on those error paths?
[ ... ]
> @@ -1272,10 +1279,10 @@ void kvm_arch_flush_shadow_all(struct kvm *kvm)
> int i;
>
> for (i = 0; i < kvm->arch.nested_mmus_size; i++) {
> - struct kvm_s2_mmu *mmu = &kvm->arch.nested_mmus[i];
> + struct kvm_s2_mmu *mmu = kvm->arch.nested_mmus[i];
>
> if (!WARN_ON(atomic_read(&mmu->refcnt)))
> - kvm_free_stage2_pgd(mmu);
> + free_nested_s2_mmu(mmu);
> }
> kvfree(kvm->arch.nested_mmus);
> kvm->arch.nested_mmus = NULL;
[Severity: High]
This is a pre-existing issue, but does this function have a race
condition with VCPU threads?
When a KVM process is killed, exit_mm() invokes mmu_notifier_release(), which
calls kvm_arch_flush_shadow_all(). This function frees kvm->arch.nested_mmus
and sets nested_mmus_size = 0 without acquiring mmu_lock.
Since file descriptors are not closed until later, VCPU threads might still be
executing. If a VCPU thread calls vcpu_load() -> kvm_vcpu_load_hw_mmu() ->
get_s2_mmu_nested(), it acquires mmu_lock but not the SRCU lock. It can read
the concurrently modified nested_mmus_size as 0, skip the lookup loop, and
execute BUG_ON(atomic_read(&s2_mmu->refcnt)) on an uninitialized or NULL
pointer.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260807195940.12642-1-kmehltretter@gmail.com?part=1
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [PATCH v4] KVM: arm64: nv: Keep the shadow S2 MMUs at fixed addresses
2026-08-07 20:17 ` sashiko-bot
@ 2026-08-08 0:06 ` Karl Mehltretter
0 siblings, 0 replies; 3+ messages in thread
From: Karl Mehltretter @ 2026-08-08 0:06 UTC (permalink / raw)
To: sashiko-reviews; +Cc: kvmarm, Oliver Upton, Marc Zyngier
On Fri, Aug 07, 2026 at 08:17:08PM +0100, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
>
> New issues:
> - [Medium] The `kvm->arch.nested_mmus` array is leaked if VM creation fails after `kvm_arch_init_vm()` completes successfully.
>
This issue is valid. generic VM-creation failures after that point can
call kvm_arch_destroy_vm() without freeing it. I’ll add the missing
kvfree(kvm->arch.nested_mmus) there in v5.
Thanks,
Karl
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-08-08 0:06 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-08-07 19:59 [PATCH v4] KVM: arm64: nv: Keep the shadow S2 MMUs at fixed addresses Karl Mehltretter
2026-08-07 20:17 ` sashiko-bot
2026-08-08 0:06 ` Karl Mehltretter
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.