Re: Bug#1135235: linux-image-6.19.13+deb14-amd64: Reoccuring host crash "Invalid SPTE change" with gaming win kvm/qemu guest and device passthrough

[Sean Christopherson]

+lists to capture this for posterity

On Wed, Jun 24, 2026, Maximilian Senftleben wrote:
> I tried a 7.0.10 with KASAN for several days, and now I am running
> 7.0.12+deb14.1-amd64 since a couple of days, and at least so far I was not
> able to reproduce my issue, i.e. I had no crash so far.

That, and the fact that 7.0.7 was fine, strongly suggests a broken fix got
backported and landed in 7.0.8 or 7.0.9, and then a fix-for-the-fix landed in
7.10.  There aren't any KVM commits of interest anywhere in that range, which
supports my theory that KVM is an innocent bystander that ran afoul of memory
corruption due to a bug elsewhere in the kernel.

Unless you want to bisect to figure out exactly what commit broken things, and
what commit fixed things, I think it makes sense to consider this resolved unless
the problem occurs on a 7.0.10+ kernel.

> On 05.06.26 23:42, Sean Christopherson wrote:
> > On Wed, Jun 03, 2026, Maximilian Senftleben wrote:
> > > Hi,
> > > 
> > > sorry for the late reply, took me a while to first built the kernel with
> > > that options and then actually find time to play long enough.
> > > 
> > > If I did everything correctly, then I build 7.0.7 with
> > > - CONFIG_VMAP_STACK=y
> > > - CONFIG_KASAN=y
> > > 
> > > I did not get it to crash on that built kernel yet, however I booted
> > > 7.0.9+deb14-amd64 once, and after playing a while got a crash again.
> > > 
> > > I will try using the built kernel next week to see if I can get it to crash
> > > as well.
> > Hmm, can you try 7.0.9 with KASAN?  Or even just a 7.0.9 kernel that you built?
> > It's possible there's a bug somewhere between 7.0.7 and 7.0.9.
> > 
> > > Or do I have to look somewhere else if kasan is active?
> > KASAN reports issues in dmesg.  But generally speaking, if the error is bad
> > enough to crash the kernel, you'll see a KASAN splat *and* a crash.
> > 
> > > On 18.05.26 15:43, Sean Christopherson wrote:
> > > > Odds are very good this is due to host memory corruption, and is not a bug in
> > > > KVM's MMU.  We (Google) had a period of time where our kernel was triggering stack
> > > > overflows if a networking IRQ hit at just the right/wrong time, and whenever the
> > > > overflow wandered into KVM page tables, it would result in failures like these.
> > > > I got quite familiar with the signature :-)
> > > Not sure if it could be something else, however I at least run memtest for
> > > ~12h without problems.
> > > > If you aren't already, can you try running with CONFIG_VMAP_STACK=y?  Stack
> > > > overflow doesn't seem likely in this case since the gfn would put the SPTE in the
> > > > middle of the page table, but it's easy enough to rule out.
> > > > 
> > > > The other thing to try would be to run with CONFIG_KASAN=y.  That might make your
> > > > gaming quite miserable, but if this is indeed due to a rogue write, it's the best
> > > > shot for catching the culprit.
> > > 
> > > Regards
> > >