Re: hunting memory corruption bug in 6.18.x

[Andrew Morton <akpm@linux-foundation.org>]

On Thu, 15 Oct 2026 20:12:42 -0700 Borislav Petkov <bp@alien8.de> wrote:

> > If that sounds sane then testing 55780d8a1dcc on that 6.18.x kernel
> > would be useful.
> 
> Hmm, dunno if that LLM sent you into the weeds. Because I ain't no virt guy
> but if vmcb01 and vmcb02 and "L2" in that commit message refer to nested virt,
> I don't think any of those crash dumps do nested virtualization.

LLM said "oops, my bad".  Then


The corruption patterns strongly resemble AMD VMCB state, particularly
FS/GS segment data appearing at the expected VMCB offsets in unrelated
host memory.  This suggests that a VMSAVE operation may have written to
an incorrect physical address.  Ordinary KVM performs VMLOAD/VMSAVE
without nested virtualization, so Boris's objection doesn't eliminate
this possibility.  However, the relevant assembly is essentially
unchanged between 6.18.55 and 7.3-rc6, and I haven't identified a newer
commit that convincingly explains why the corruption apparently stopped
reproducing.  The earlier candidate 55780d8a1dcc remains poorly
motivated without evidence of nested virtualization.

Two investigations look worthwhile.  First, test 6.18.55 with both the
KVM TLB-flush fix (26505e1b5b54) and tlbi=ipi; the existing results
don't conclusively establish whether that combination was tested. 
Second, examine the vmcore to determine whether the corrupted host
pages contain complete FS/GS state matching a legitimate VMCB, rather
than merely a few matching values.  If they do, inspect the VMCB's
VMLOAD/VMSAVE interception and virtualization-enable bits.  That could
establish whether a hardware VMSAVE was allowed to write to an
unintended physical page.  The successful 7.3-rc6/rc7 testing is
encouraging, but it doesn't yet prove that all the reported corruption
symptoms share one cause or have been fixed.