Re: [PATCH] KVM: nSVM: Snapshot vmcb12 save.rip to prevent TOCTOU race

[Paolo Bonzini]

On Wed, Apr 1, 2026 at 6:57 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
> Eh, I wouldn't call this dangerous per se.  Problematic, sure, but AFAICT the
> host is never at risk.  My official stance is that any panics due to KVM WARNs
> when running with panic_on_warn=1 are NOT considered KVM DoS issues.

Yes. More in general panic_on_warn=1 is only a good idea in two cases:
1) because there's a much bigger vulnerability that you know about and
can't patch, and you want to somehow mitigate it 2) because you
(relatively speaking) don't care about availability, which means that
treating WARNs as vulnerabilities is misleading.

If someone (like a distro or an Android vendor, I don't know) sets
panic_on_warn=1 without having evaluated (2), it's entirely on them.
(Please, no bickering about the definition of vulnerability. It's
perfectly possible for CNAs to describe configurations where reduced
definitions of vulnerability apply, and "the user asked for it" can be
one such configuration.)

> KVM WARNs are 100% worth fixing, especially if they're guest- and/or user-triggerable,
> but the WARNs themselves aren't security/DoS issues, because in my very strong
> opinion, allowing use of /dev/kvm with panic_on_warn=1 when the platform owner
> cares about host uptime is user/admin error.

Yes.

> There are many, many nSVM issues that need to be fixed, many of which are functional
> problems for well-behaved setups.  For me, those are by far the priority.  I also
> want to fix the a guest-triggerable WARN_ON_ONCE(), but it's not urgent, and not
> something I want to spend a lot of effort on with respect to providing an LTS-friendly
> commit (though if we can get one cheaply, that'd be great).

Plus in the presence of large-scale refactorings and fixes over the
years presence of issues is hard to ascertain mechanically. Older LTS
versions won't even have struct vmcb_save_area_cached and may
incorrectly register as "not having this issue", while the actual
situation of nSVM there is much worse than top of tree.

And for the same reason backports can be hard to evaluate. Sure WARNs
tend to be of the "ok, I was overly conservative and didn't think of
these circumstances", which is on the easy side, but there is a reason
why KVM requested no stable autoselect.

Paolo