On 2/28/24 09:14, Greg Kroah-Hartman wrote:
> From: [email protected]
>
> 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.
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.
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
- there is no list gathering all the discussions/complaints about these
CVEs, since I cannot reply to [email protected].
This is not the way to run this, and you're not getting more complaints
just because people don't care, not because it's all fine.
Paolo
[1]
https://lore.kernel.org/linux-cve-announce/2024022259-CVE-2024-26592-58f7@gregkh/T/#u
> When enlightened VMCS is in use and nested state is migrated with
> vmx_get_nested_state()/vmx_set_nested_state() KVM can't map evmcs
> page right away: evmcs gpa is not 'struct kvm_vmx_nested_state_hdr'
> and we can't read it from VP assist page because userspace may decide
> to restore HV_X64_MSR_VP_ASSIST_PAGE after restoring nested state
> (and QEMU, for example, does exactly that). To make sure eVMCS is
> mapped /vmx_set_nested_state() raises KVM_REQ_GET_NESTED_STATE_PAGES
> request.
>
> Commit f2c7ef3ba955 ("KVM: nSVM: cancel KVM_REQ_GET_NESTED_STATE_PAGES
> on nested vmexit") added KVM_REQ_GET_NESTED_STATE_PAGES clearing to
> nested_vmx_vmexit() to make sure MSR permission bitmap is not switched
> when an immediate exit from L2 to L1 happens right after migration (caused
> by a pending event, for example). Unfortunately, in the exact same
> situation we still need to have eVMCS mapped so
> nested_sync_vmcs12_to_shadow() reflects changes in VMCS12 to eVMCS.
>
> As a band-aid, restore nested_get_evmcs_page() when clearing
> KVM_REQ_GET_NESTED_STATE_PAGES in nested_vmx_vmexit(). The 'fix' is far
> from being ideal as we can't easily propagate possible failures and even if
> we could, this is most likely already too late to do so. The whole
> 'KVM_REQ_GET_NESTED_STATE_PAGES' idea for mapping eVMCS after migration
> seems to be fragile as we diverge too much from the 'native' path when
> vmptr loading happens on vmx_set_nested_state().
>
> The Linux kernel CVE team has assigned CVE-2021-46978 to this issue.
>
>
> Affected and fixed versions
> ===========================
>
> Issue introduced in 5.10.13 with commit 0faceb7d6dda and fixed in 5.10.38 with commit c8bf64e3fb77
> Issue introduced in 5.11 with commit f2c7ef3ba955 and fixed in 5.11.22 with commit 200a45649ab7
> Issue introduced in 5.11 with commit f2c7ef3ba955 and fixed in 5.12.5 with commit bd0e8455b85b
> Issue introduced in 5.11 with commit f2c7ef3ba955 and fixed in 5.13 with commit f5c7e8425f18
>
> Please see https://www.kernel.org or a full list of currently supported
> kernel versions by the kernel community.
>
> Unaffected versions might change over time as fixes are backported to
> older supported kernel versions. The official CVE entry at
> https://cve.org/CVERecord/?id=CVE-2021-46978
> will be updated if fixes are backported, please check that for the most
> up to date information about this issue.
>
>
> Affected files
> ==============
>
> The file(s) affected by this issue are:
> arch/x86/kvm/vmx/nested.c
>
>
> Mitigation
> ==========
>
> The Linux kernel CVE team recommends that you update to the latest
> stable kernel version for this, and many other bugfixes. Individual
> changes are never tested alone, but rather are part of a larger kernel
> release. Cherry-picking individual commits is not recommended or
> supported by the Linux kernel community at all. If however, updating to
> the latest release is impossible, the individual changes to resolve this
> issue can be found at these commits:
> https://git.kernel.org/stable/c/c8bf64e3fb77cc19bad146fbe26651985b117194
> https://git.kernel.org/stable/c/200a45649ab7361bc80c70aebf7165b64f9a6c9f
> https://git.kernel.org/stable/c/bd0e8455b85b651a4c77de9616e307129b15aaa7
> https://git.kernel.org/stable/c/f5c7e8425f18fdb9bdb7d13340651d7876890329
>
On Wed, Feb 28, 2024 at 11:09:50PM +0100, Paolo Bonzini wrote:
> On 2/28/24 09:14, Greg Kroah-Hartman wrote:
> > From: [email protected]
> >
> > 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 [email protected].
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
Greg KH <[email protected]> writes:
> On Wed, Feb 28, 2024 at 11:09:50PM +0100, Paolo Bonzini wrote:
>> On 2/28/24 09:14, Greg Kroah-Hartman wrote:
>> > From: [email protected]
>> >
>> > 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 be precise, this issue is about guest's behavior post-migration and
not booting. Also, it should be noted that "Enlightened VMCS" feature is
normally not used for Linux guests on KVM so the "guest kernel" is
actually Windows kernel (or Hyper-V) :-)
Personally, I don't see how this particular issue differs from other KVM
hypervisor bugs. I.e. when hypervisor misbehaves, the guest will likely
suffer and in many cases "suffer" means crash. What *is* important is
who can trigger hypervisor's misbehavior. In case it is guest triggered
(and especially if triggered from CPL!=0), security implications are
possible. In the even worse case when such guest's actions can cause
issues in the host's kernel, the presence of a vulnerability is almost
certain.
Migration is (normally) not guest triggered, it's a deliberate action on
the host.
--
Vitaly
On Thu, Feb 29, 2024 at 6:21 AM Greg KH <[email protected]> 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: [email protected]
> > >
> > > 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 [email protected].
>
> 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
On Thu, Feb 29, 2024 at 11:04:45AM +0100, Paolo Bonzini wrote:
> 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.
I believe the url https://lore.kernel.org/all/<message-id> will get
the whole thread, regardless of which mailing lists individual mail
messages were sent to, does it not?
- Ted
On 2/29/24 15:34, Theodore Ts'o wrote:
> On Thu, Feb 29, 2024 at 11:04:45AM +0100, Paolo Bonzini wrote:
>> 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.
>
> I believe the url https://lore.kernel.org/all/<message-id> will get
> the whole thread, regardless of which mailing lists individual mail
> messages were sent to, does it not?
Yes, it does. That covers the web interface but it still leaves out
subscribers and people reading via NNTP.
That said, I'm not sure why people who look at CVEs for a living should
not have their own lighter-traffic mailing list, which was the main
reason to have a linux-cve mailing list.
Paolo