Re: [REGRESSION] KVM: x86: OVMF boot hang with SMM enabled after commit b3e6212dea2e ("KVM: x86: Use active memslots for the per-vCPU MMIO cache")

[Sean Christopherson <seanjc@google.com>]

On Tue, Oct 27, 2026, Sami Farin wrote:
> On Fri, Oct 23, 2026 at 14:45:15 +0200, Greg Kroah-Hartman wrote:
> > From: Greg Kroah-Hartman <gregkh@kernel.org>
> > 
> > Description
> > ===========
> > 
> > In the Linux kernel, the following vulnerability has been resolved:
> > 
> > KVM: x86: Use active memslots for the per-vCPU MMIO cache
> 
> Hi all,
> 
> (Disclaimer: I am an end user, not a kernel developer. I used an LLM to help
> triage and trace the issue, but the findings, traces, and tests below are verified.)
> 
> I hit a guest boot hang after updating my host from 6.18.57 to 6.18.58 (Fedora 44).
> Windows 11 guests using OVMF with Secure Boot and SMM (-machine q35,smm=on) hang
> indefinitely at the TianoCore splash screen, pegging the host vCPU core at 100%.
> 
> The issue bisects/points directly to commit b3e6212dea2e ("KVM: x86: Use active
> memslots for the per-vCPU MMIO cache"), which was backported into 6.18.58 and is
> also present in 7.3-rc kvm/queue.

...

> ########### patch 1
>     The proper upstream fix requires tagging the per-vCPU MMIO cache with the address space ID (as_id) alongside the generation counter.
>     The Flaw in Commit b3e6212dea2e:
>     The commit attempted to fix stale MMIO cache validation in SMM by checking kvm_vcpu_memslots(vcpu)->generation. However, its commit message relied on an incorrect assumption:
>         "Memslot generations are unique across address spaces, so the generation also distinguishes the normal and SMM views."
>     In KVM, each address space maintains an independent struct kvm_memslots with its own generation counter initialized to 0. They are not unique across address spaces. During early VM boot, address space 0 (Normal) and address space 1 (SMM) frequently have identical generation numbers.
>     Because struct kvm_vcpu_arch only stores a single GVA, GFN, and generation counter without an address space identifier:
>         An MMIO access cached in SMM (e.g., GFN 0xFED40000 with gen = 4) matches in normal mode where gen is also 4.

Hmm, this isn't adding up for me.  It should be impossible for the generation to
be '4' for SMM, because SMM is supposed to use odd-numbered generations.  From
kvm_swap_active_memslots():

	/*
	 * Generations must be unique even across address spaces.  We do not need
	 * a global counter for that, instead the generation space is evenly split
	 * across address spaces.  For example, with two address spaces, address
	 * space 0 will use generations 0, 2, 4, ... while address space 1 will
	 * use generations 1, 3, 5, ...
	 */
	gen += kvm_arch_nr_memslot_as_ids(kvm); 

So while both of the suggested fixes seem reasonable, they _should_ be unnecessary.

Paolo, at PUCK I verbally said we could go with the one-line fix, but I'd prefer
to hold off until we can figure out why the generations collide in the first place.