Re: hunting memory corruption bug in 6.18.x

[Andrew Morton]

On Wed, 14 Oct 2026 16:57:36 -0700 Borislav Petkov <bp@xxxxxxxxx> wrote:

> On Mon, Oct 12, 2026 at 01:43:30PM +0200, Nikola Ciprich wrote:
> > Since I didn’t have anything else to try, and we started having
> > crashes on our own cluster nodes, where I can be a bit bolder,
> > I built 7.3-rc6, deployed it on two problematic AMD nodes, and
> > started a migration torture loop.
> > 
> > Over the weekend, there were ~70 migrations of ~160 VMs between
> > those two nodes without a single issue.
> 
> Did it reproduce usually with this?
> 
> If not, keep hammering on it with the latest kernel. We might've fixed
> whatever that was, along the way. :-(
> 
> And if so, that would be a damn nasty bisection to figure out what fixed it...
> 
> So pls hammer on it as long as possible to see if it is really fixed or it is
> simply harder to repro.

fwiw, I fed a lot of tokens into $LLM and it suggests that 55780d8a1dcc
fixed this.

If that sounds sane then testing 55780d8a1dcc on that 6.18.x kernel
would be useful.


: The repeated structures appear to be AMD VMCBs: 0x0fffffff0c930020
: decodes as segment state (selector 0x20, attributes 0xc93, limit
: 0x0fffffff), not a damaged pointer.  The FS/GS offsets in the dcache
: corruption and the LSTAR/CSTAR/SFMASK offsets in the earlier library
: corruption suggest misplaced VMLOAD/VMSAVE state transfers.  A
: candidate fix is 55780d8a1dcc (KVM: SVM: Stop toggling virtual
: VMSAVE/VMLOAD on intercept recalc), which is absent from the inspected
: v6.18.53/v6.18.55 code.  In the affected
: svm_recalc_instruction_intercepts(), VMLOAD/VMSAVE interception is
: changed in vmcb01, but virtualization enablement is changed in the
: currently selected VMCB, potentially vmcb02.
: 
: Although the commit describes this mismatch as benign, restoring a
: fresh destination vCPU directly into L2 appears to expose a case that
: assessment overlooks: deferred intercept recalculation could clear
: vmcb01s intercepts while enabling virtualization only in vmcb02,
: leaving L1s subsequent VMLOAD/VMSAVE instructions neither intercepted
: nor virtualized.  That could make guest-supplied physical addresses
: target host memory, consistent with the observed corruption.  This is a
: source-derived hypothesis, not a reproduced root cause, and depends on
: an affected vCPU actually being restored in nested guest mode.  Could
: we confirm that condition and test a backport of 55780d8a1dcc?  A
: useful vmcore check would also be whether any live vCPUs vmcb01 has
: both VMLOAD/VMSAVE intercepts clear and the virtual-VMLOAD/VMSAVE
: enable bit clear.