From: Marc Zyngier <maz@kernel.org>
To: Fuad Tabba <fuad.tabba@linux.dev>
Cc: sashiko-reviews@lists.linux.dev, kvmarm@lists.linux.dev,
Oliver Upton <oupton@kernel.org>
Subject: Re: [PATCH v2 2/4] KVM: arm64: vgic: Don't leak the SPI array when init is retried
Date: Fri, 07 Aug 2026 16:59:21 +0100 [thread overview]
Message-ID: <87fr0pq5uu.wl-maz@kernel.org> (raw)
In-Reply-To: <CA+EHjTwVKkAwWUeMrF_m2-35kyhESqAezOKJy-Pj=vA3qE5Bjw@mail.gmail.com>
On Fri, 07 Aug 2026 13:15:52 +0100,
Fuad Tabba <fuad.tabba@linux.dev> wrote:
>
> On Fri, 7 Aug 2026 at 11:56, <sashiko-bot@kernel.org> wrote:
> >
> > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
>
> No, thank _you_ Sashiko!
>
> >
> > Pre-existing issues:
> > - [High] If `vgic_init()` fails after `vgic_v4_init()` succeeds, the VPE array is left allocated but `vgic_initialized` remains false. Userspace can then create additional VCPUs and retry `vgic_init()`. The second `vgic_v4_init()` returns early because the VPE array is already allocated, leaving the new VCPUs without initialized VPE IRQs.
> ...
> > When a new VCPU runs, `vgic_v4_load()` calls `irq_set_affinity()` with an uninitialized IRQ (0), which fails and triggers a host `WARN_ON`, causing a host-side denial of service.
>
> This is a separate fix. But you're right about the state.
> kvm_arch_vcpu_precreate() only refuses vCPUs once vgic_initialized()
> is true, so the retry admits one the VPE array does not cover.
>
> I don't think a VMM can drive it. kvm_vgic_setup_default_irq_routing()
> is the only failure after vgic_v4_init(), and it builds its own
> routing entries, so nothing short of a real -ENOMEM fails it.
>
> The fix I have in mind keeps vgic_v4_init() idempotent, as this patch
> is: return early only while the vCPU count is unchanged, rebuild when
> it grew. That needs its_free_vcpu_irqs() to clear vm->domain and
> vm->fwnode first, which it does not today, so its_alloc_vcpu_irqs()
> can reach its error path with a domain it has already removed.
>
> Let me think about it some more and I'll send something once others
> have had a chance to digest this as well.
I don't think we should grow anything opportunistically.
The GICv4 code expects the number of vcpus to be fixed when first
initialised, and if we must fail it one way or another, then
everything should be torn down and reinitialised from scratch.
I really don't want to have to think about the intermediate state.
Thanks,
M.
--
Jazz isn't dead. It just smells funny.
next prev parent reply other threads:[~2026-08-07 15:58 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-07 10:40 [PATCH v2 0/4] KVM: arm64: vgic: Fixes for ITS table save and init retry Fuad Tabba
2026-08-07 10:40 ` [PATCH v2 1/4] KVM: arm64: vgic-its: Don't dereference a NULL collection on ITT save Fuad Tabba
2026-08-07 10:41 ` [PATCH v2 2/4] KVM: arm64: vgic: Don't leak the SPI array when init is retried Fuad Tabba
2026-08-07 10:55 ` sashiko-bot
2026-08-07 12:15 ` Fuad Tabba
2026-08-07 15:59 ` Marc Zyngier [this message]
2026-08-07 10:41 ` [PATCH v2 3/4] KVM: arm64: vgic-its: Don't save collections the table cannot hold Fuad Tabba
2026-08-08 8:10 ` Marc Zyngier
2026-08-07 10:41 ` [PATCH v2 4/4] KVM: arm64: vgic-its: Point saved ITEs at the next valid entry Fuad Tabba
2026-08-08 18:35 ` [PATCH v2 0/4] KVM: arm64: vgic: Fixes for ITS table save and init retry Oliver Upton
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=87fr0pq5uu.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=fuad.tabba@linux.dev \
--cc=kvmarm@lists.linux.dev \
--cc=oupton@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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.