Re: x86/KVM: host reads guest IDT gates after VMexit on Cascade Lake

[Jim Mattson]

On Wed, Aug 26, 2026 at 4:19 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
>
> +Chao, who has helped with errata in the past
>
> On Wed, Aug 26, 2026, Yaohui Hu wrote:
> > Hi,
> >
> > We are chasing a host crash on Intel Cascade Lake that we believe is a
> > CPU defect, but the exposure changed sharply across a kernel upgrade
> > and we would like input on the kernel side.
> >
> > Symptom: nine hypervisor crashes over ~120 days, all the same shape.
> > On a KVM vCPU thread, shortly after a VM-exit, the host faults at an
> > address unmapped in the host, then faults again on every subsequent
> > exception delivery, recursing until the #DF stack is exhausted.
> >
> > The phantom handler addresses are not random. In one dump we located
> > the IDT they came from: it lives in the tmpfs-backed guest RAM of the
> > VM running on that CPU. The host read gate descriptors out of the
> > *guest's* IDT and tried to deliver host exceptions to guest handler
> > addresses. A second dump shows this in software rather than by
> > inference, with the oops registers caught in vmx_do_interrupt_irqoff()
> > having read a garbage gate from host_idt_base.
> >
> > Linux maps the IDT through the CPU-entry-area alias at a fixed
> > virtual address (0xfffffe0000000000) that KASLR never relocates, so a
> > Linux guest and a Linux host use the same address for their own IDTs.
> > With VPID enabled the guest's translation survives the VM-exit, and a
> > host access tagged VPID 0000H must not match the guest-tagged entry.
> > On these parts it appears to.
> >
> > Environment:
> >
> >   - Xeon, family 6 model 85 stepping 7 (Cascade Lake-SP), microcode
> >     0x05003901 (latest public for this stepping) on all nine hosts.
> >   - Two server vendors, three datacenters, VPID enabled.
> >   - 6.1.51 ran this fleet without such a crash; 6.12.51 produces
> >     them. Microcode and hardware are unchanged across the upgrade.
> >
> > There is a documented precedent for the failure class on a different
> > part: Arrow Lake erratum ARL029, "Incorrect Core TLB Entry May be
> > Retrieved Following VM Exit". Cascade Lake has no public equivalent.
> >
> > We diffed the relevant paths between the two versions. The gate read
> > in handle_external_interrupt_irqoff() is functionally identical, and
> > the TLB/VPID/EPT invalidation layer is byte-identical
> > (vmx_flush_tlb_*, allocate_vpid, vmx_vcpu_load_vmcs, and the
> > INVVPID/INVEPT sites), so we do not believe KVM changed its
> > invalidation behaviour. The one change we found that plausibly alters
> > exposure is 97e3d26b5e5f ("x86/mm: Randomize per-cpu entry area",
> > v6.2), which changes the paging topology of exactly this region. We
> > can see the effect in our builds, but we have no mechanism that
> > predicts its sign.
> >
> > Questions:
> >
> > 1. Has anyone seen this signature? A host faulting after VM-exit at
> >    an address that turns out to belong to a guest seems distinctive
> >    enough to be memorable.
>
It doesn't ring a bell, but I'm curious if it goes away with
hyperthreading disabled.