Re: CVE-2021-46978: KVM: nVMX: Always make an attempt to map eVMCS after migration

[Greg KH <gregkh@kernel.org>]

On Wed, Feb 28, 2024 at 11:09:50PM +0100, Paolo Bonzini wrote:
> On 2/28/24 09:14, Greg Kroah-Hartman wrote:
> > From: gregkh@kernel.org
> > 
> > Description
> > ===========
> > 
> > In the Linux kernel, the following vulnerability has been resolved:
> > 
> > KVM: nVMX: Always make an attempt to map eVMCS after migration
> 
> How does this break the confidentiality, integrity or availability of the
> host kernel?  It's a fix for a failure to restart the guest after migration.
> Vitaly can confirm.

It's a fix for the availability of the guest kernel, which now can not
boot properly, right?  That's why this was selected.  If this is not
correct, I will be glad to revoke this.

> Apparently the authority to "dispute or modify an assigned CVE lies solely
> with the maintainers", but we don't have the authority to tell you in
> advance that a CVE is crap, so please consider this vulnerability to be
> disputed.

Great, but again, not allowing the guest kernel to boot again feels like
an "availability" issue to me.  If not, we can revoke this.

> Unlike what we discussed last week:
> 
> - the KVM list is not CC'd so whoever sees this reply will have to find the
> original message on their own

Adding a cc: to the subsystem mailing list for the CVEs involved can be
done, but would it really help much?

> - there is no list gathering all the discussions/complaints about these
> CVEs, since I cannot reply to linux-cve-announce@vger.kernel.org.

That's what lkml is for, and is why the "Reply-to:" is set on the
linux-cve-announce emails.  Creating yet-another-list isn't really going
to help much.

Also, this is part of the "import the GSD database into CVE" which the
CVE project asked us to do, which is why these "old" issues are popping
up now.

thanks,

greg k-h