From: Michael Bommarito <michael.bommarito@gmail.com>
To: Marc Zyngier <maz@kernel.org>, Oliver Upton <oupton@kernel.org>
Cc: Joey Gouly <joey.gouly@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Zenghui Yu <yuzenghui@huawei.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: [PATCH] KVM: arm64: vgic: free private_irqs when init fails after allocation
Date: Sun, 17 May 2026 14:13:31 -0400 [thread overview]
Message-ID: <20260517181331.367676-1-michael.bommarito@gmail.com> (raw)
Companion to commit 250f25367b58 ("KVM: arm64: Tear down vGIC on failed
vCPU creation"), which added the missing kvm_vgic_vcpu_destroy() call
to the kvm_share_hyp() failure path in kvm_arch_vcpu_create(). The
kvm_vgic_vcpu_init() failure path immediately above it has the same
shape and still needs the same cleanup.
If kvm_vgic_vcpu_init() allocates per-vCPU private IRQs via
vgic_allocate_private_irqs_locked() and then vgic_register_redist_iodev()
fails (for example when kvm_io_bus_register_dev() runs out of MMIO-bus
slots, or vgic_v3_check_base() rejects the configuration), the function
returns the error without freeing the private-IRQ allocation.
The caller kvm_arch_vcpu_create() returns this error directly, and
kvm_vm_ioctl_create_vcpu() jumps to vcpu_free_run_page on
kvm_arch_vcpu_create() failure, which does not invoke
kvm_arch_vcpu_destroy(). The vCPU struct is then released via
kmem_cache_free(kvm_vcpu_cache, ...), dropping the only reference to
the leaked allocation.
The comment block above __kvm_vgic_vcpu_destroy() explicitly anticipates
this case ("vCPUs that failed creation are torn down outside of the
kvm->arch.config_lock ... it is both safe and necessary to do so
here"), but the caller never actually invokes the destroy primitive on
the kvm_vgic_vcpu_init() error path. Call it now, mirroring the shape
of the kvm_share_hyp() cleanup added by 250f25367b58.
Per-failure leak is VGIC_NR_PRIVATE_IRQS * sizeof(struct vgic_irq),
roughly 3.8 KiB rounded up to 4 KiB by the kmalloc-cg-4k slab. On
systems whose /dev/kvm policy lets unprivileged users open the device
this is reachable to any local user; reach is policy-dependent and
varies by distro and packager.
Confirmed with kmemleak on v7.1-rc1+: 50 failed KVM_CREATE_VCPU
attempts (run with the per-VM MMIO bus pre-filled to NR_IOBUS_DEVS so
vgic_register_redist_iodev() returns -ENOSPC) leave 49 unreferenced
4096-byte blocks whose allocation backtrace is
__kmalloc_noprof+0x390/0x4d0
vgic_allocate_private_irqs_locked+0x68/0x1c8
kvm_vgic_vcpu_init+0x78/0xd8
With this patch applied to the same tree, kmemleak reports zero
unreferenced objects under the identical workload.
Cc: stable@vger.kernel.org
Cc: Will Deacon <will@kernel.org>
Assisted-by: Claude:claude-opus-4-7
Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
---
arch/arm64/kvm/arm.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 176cbe8baad30..5d5e2f81b9c94 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -554,8 +554,10 @@ int kvm_arch_vcpu_create(struct kvm_vcpu *vcpu)
kvm_destroy_mpidr_data(vcpu->kvm);
err = kvm_vgic_vcpu_init(vcpu);
- if (err)
+ if (err) {
+ kvm_vgic_vcpu_destroy(vcpu);
return err;
+ }
err = kvm_share_hyp(vcpu, vcpu + 1);
if (err)
--
2.53.0
next reply other threads:[~2026-05-17 18:13 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-17 18:13 Michael Bommarito [this message]
2026-05-18 5:28 ` [PATCH] KVM: arm64: vgic: free private_irqs when init fails after allocation Yao Yuan
2026-05-18 5:31 ` Yao Yuan
2026-05-19 0:26 ` Michael Bommarito
2026-05-19 7:53 ` Marc Zyngier
2026-05-19 13:50 ` [PATCH v2] " Michael Bommarito
2026-05-20 7:17 ` Marc Zyngier
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=20260517181331.367676-1-michael.bommarito@gmail.com \
--to=michael.bommarito@gmail.com \
--cc=catalin.marinas@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=maz@kernel.org \
--cc=oupton@kernel.org \
--cc=suzuki.poulose@arm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox