Re: hunting memory corruption bug in 6.18.x

[Borislav Petkov]

On Thu, Oct 15, 2026 at 09:18:32PM -0700, Andrew Morton wrote:
> The corruption patterns strongly resemble AMD VMCB state, particularly
> FS/GS segment data appearing at the expected VMCB offsets in unrelated
> host memory.

Aha, ok.

> 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)

Pff, we've been looking at that one recently too, trying to figure out whether
it was really necessary.

> and tlbi=ipi;

Yeah, we checked that, it ain't that.

> 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.

Hmm. I guess looking at and around VMSAVE handling wouldn't hurt...

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette