Re: [PATCH v2 3/4] KVM: arm64: vgic-its: Don't save collections the table cannot hold
Marc Zyngier <[email protected]> Sat, 08 Aug 2026 09:10:29 +0100
| Newsgroups | dev.linux.lists.kvmarm,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
On Fri, 07 Aug 2026 11:41:01 +0100, Fuad Tabba <[email protected]> wrote: > > A guest that disables the ITS and rewrites GITS_BASER with fewer pages, > VALID still set, keeps every collection it mapped against the larger > table: KVM stores the new BASER unconditionally and frees the list only > when VALID is cleared. But isn't that the *real* problem? Shouldn't we instead nuke the collections entirely and go through a reload sequence? > vgic_its_save_collection_table() then walks the > whole list, writing up to 448K past the end of the table, and saves > collection IDs that vgic_its_restore_cte() rejects, so the save succeeds > and the restore fails with -EINVAL on the destination. The overrun stays > in guest memory, as vgic_write_guest_lock() validates every gfn. > > Validate each collection against the current table with > vgic_its_check_id() and return -EINVAL, as vgic_its_save_device_tables() > does for devices. Collection IDs are unique and the collection table is > never indirect, so the check also bounds the walk. I think returning -EINVAL here was a mistake, as it aborts the save procedure that userspace should be able to issue reliably, even if that means the state is crap. I don't think we should expand that behaviour any further. M. -- Jazz isn't dead. It just smells funny.