On Thu, Feb 29, 2024 at 6:21 AM Greg KH <gregkh@xxxxxxxxxx> wrote: > > 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@xxxxxxxxxx > > > > > > 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. To expand on what Vitaly touched, guest availability based on host action is generally not considered part of the threat model (not even by the newfangled confidential computing stuff). If you want to stop a guest, run "virsh pause" or kill -9. Add load to the host until the guest reports a lockup. dd if=/dev/random to their disk. Or if you need to bypass SELinux, just turn off the host---in CVSS parlance, that would be a valid attack on an "adjacent" machine, but nobody treats it as such and the reason should be obvious. Yes, there can be mitigations but let's say that "orchestrate a fake migration so that the guest fails to restart on the destination" is fairly down on the checklsit. > > 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? Yes, it would give a heads up like you do for stable patches roundup. > > - there is no list gathering all the discussions/complaints about these > > CVEs, since I cannot reply to linux-cve-announce@xxxxxxxxxxxxxxx. > > 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. So why do we have subsystem lists at all? It helps people that have interest in proposing and gathering CVE disputes, providing an easy way to do so; just like subsystem mailing lists people that are interested in USB or virtualization patches. It helps searching for all messages related to a CVE by not splitting them between linux-cve-announce and lkml, too. Also, LKML does not get the initial announcement, which makes it a bit more painful to find the full discussion on lore (you have to go through a "no message with that id, maybe you mean this one from other mailing lists" page, instead of having the whole thread in the same place). A linux-cve mailing list with public posting, used for Cc and Reply-to of the initial message, would solve this issue as well. Paolo
