* FAILED: patch "[PATCH] KVM: x86/mmu: fix NULL pointer dereference on guest INVPCID" failed to apply to 5.17-stable tree
@ 2022-05-21 13:58 gregkh
2022-05-24 15:11 ` [PATCH] KVM: x86/mmu: fix NULL pointer dereference on guest INVPCID Vegard Nossum
0 siblings, 1 reply; 7+ messages in thread
From: gregkh @ 2022-05-21 13:58 UTC (permalink / raw)
To: pbonzini, kangel; +Cc: stable
The patch below does not apply to the 5.17-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 9f46c187e2e680ecd9de7983e4d081c3391acc76 Mon Sep 17 00:00:00 2001
From: Paolo Bonzini <pbonzini@redhat.com>
Date: Fri, 20 May 2022 13:48:11 -0400
Subject: [PATCH] KVM: x86/mmu: fix NULL pointer dereference on guest INVPCID
With shadow paging enabled, the INVPCID instruction results in a call
to kvm_mmu_invpcid_gva. If INVPCID is executed with CR0.PG=0, the
invlpg callback is not set and the result is a NULL pointer dereference.
Fix it trivially by checking for mmu->invlpg before every call.
There are other possibilities:
- check for CR0.PG, because KVM (like all Intel processors after P5)
flushes guest TLB on CR0.PG changes so that INVPCID/INVLPG are a
nop with paging disabled
- check for EFER.LMA, because KVM syncs and flushes when switching
MMU contexts outside of 64-bit mode
All of these are tricky, go for the simple solution. This is CVE-2022-1789.
Reported-by: Yongkang Jia <kangel@zju.edu.cn>
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index 56ebc4fb7f91..45e1573f8f1d 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -5470,14 +5470,16 @@ void kvm_mmu_invpcid_gva(struct kvm_vcpu *vcpu, gva_t gva, unsigned long pcid)
uint i;
if (pcid == kvm_get_active_pcid(vcpu)) {
- mmu->invlpg(vcpu, gva, mmu->root.hpa);
+ if (mmu->invlpg)
+ mmu->invlpg(vcpu, gva, mmu->root.hpa);
tlb_flush = true;
}
for (i = 0; i < KVM_MMU_NUM_PREV_ROOTS; i++) {
if (VALID_PAGE(mmu->prev_roots[i].hpa) &&
pcid == kvm_get_pcid(vcpu, mmu->prev_roots[i].pgd)) {
- mmu->invlpg(vcpu, gva, mmu->prev_roots[i].hpa);
+ if (mmu->invlpg)
+ mmu->invlpg(vcpu, gva, mmu->prev_roots[i].hpa);
tlb_flush = true;
}
}
^ permalink raw reply related [flat|nested] 7+ messages in thread
* [PATCH] KVM: x86/mmu: fix NULL pointer dereference on guest INVPCID
2022-05-21 13:58 FAILED: patch "[PATCH] KVM: x86/mmu: fix NULL pointer dereference on guest INVPCID" failed to apply to 5.17-stable tree gregkh
@ 2022-05-24 15:11 ` Vegard Nossum
2022-05-24 15:22 ` Greg KH
0 siblings, 1 reply; 7+ messages in thread
From: Vegard Nossum @ 2022-05-24 15:11 UTC (permalink / raw)
To: stable; +Cc: Sean Christopherson, Paolo Bonzini, Yongkang Jia, Vegard Nossum
From: Paolo Bonzini <pbonzini@redhat.com>
commit 9f46c187e2e680ecd9de7983e4d081c3391acc76 upstream.
With shadow paging enabled, the INVPCID instruction results in a call
to kvm_mmu_invpcid_gva. If INVPCID is executed with CR0.PG=0, the
invlpg callback is not set and the result is a NULL pointer dereference.
Fix it trivially by checking for mmu->invlpg before every call.
There are other possibilities:
- check for CR0.PG, because KVM (like all Intel processors after P5)
flushes guest TLB on CR0.PG changes so that INVPCID/INVLPG are a
nop with paging disabled
- check for EFER.LMA, because KVM syncs and flushes when switching
MMU contexts outside of 64-bit mode
All of these are tricky, go for the simple solution. This is CVE-2022-1789.
Reported-by: Yongkang Jia <kangel@zju.edu.cn>
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
[fix conflict due to missing b9e5603c2a3accbadfec570ac501a54431a6bdba]
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
---
arch/x86/kvm/mmu/mmu.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index e7cd16e1e0a0b..ff65584c7e5f4 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -5416,14 +5416,16 @@ void kvm_mmu_invpcid_gva(struct kvm_vcpu *vcpu, gva_t gva, unsigned long pcid)
uint i;
if (pcid == kvm_get_active_pcid(vcpu)) {
- mmu->invlpg(vcpu, gva, mmu->root_hpa);
+ if (mmu->invlpg)
+ mmu->invlpg(vcpu, gva, mmu->root_hpa);
tlb_flush = true;
}
for (i = 0; i < KVM_MMU_NUM_PREV_ROOTS; i++) {
if (VALID_PAGE(mmu->prev_roots[i].hpa) &&
pcid == kvm_get_pcid(vcpu, mmu->prev_roots[i].pgd)) {
- mmu->invlpg(vcpu, gva, mmu->prev_roots[i].hpa);
+ if (mmu->invlpg)
+ mmu->invlpg(vcpu, gva, mmu->prev_roots[i].hpa);
tlb_flush = true;
}
}
--
2.35.1.46.g38062e73e0
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH] KVM: x86/mmu: fix NULL pointer dereference on guest INVPCID
2022-05-24 15:11 ` [PATCH] KVM: x86/mmu: fix NULL pointer dereference on guest INVPCID Vegard Nossum
@ 2022-05-24 15:22 ` Greg KH
2022-05-24 15:27 ` Vegard Nossum
0 siblings, 1 reply; 7+ messages in thread
From: Greg KH @ 2022-05-24 15:22 UTC (permalink / raw)
To: Vegard Nossum; +Cc: stable, Sean Christopherson, Paolo Bonzini, Yongkang Jia
On Tue, May 24, 2022 at 05:11:18PM +0200, Vegard Nossum wrote:
> From: Paolo Bonzini <pbonzini@redhat.com>
>
> commit 9f46c187e2e680ecd9de7983e4d081c3391acc76 upstream.
>
> With shadow paging enabled, the INVPCID instruction results in a call
> to kvm_mmu_invpcid_gva. If INVPCID is executed with CR0.PG=0, the
> invlpg callback is not set and the result is a NULL pointer dereference.
> Fix it trivially by checking for mmu->invlpg before every call.
>
> There are other possibilities:
>
> - check for CR0.PG, because KVM (like all Intel processors after P5)
> flushes guest TLB on CR0.PG changes so that INVPCID/INVLPG are a
> nop with paging disabled
>
> - check for EFER.LMA, because KVM syncs and flushes when switching
> MMU contexts outside of 64-bit mode
>
> All of these are tricky, go for the simple solution. This is CVE-2022-1789.
>
> Reported-by: Yongkang Jia <kangel@zju.edu.cn>
> Cc: stable@vger.kernel.org
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> [fix conflict due to missing b9e5603c2a3accbadfec570ac501a54431a6bdba]
> Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
> ---
> arch/x86/kvm/mmu/mmu.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
What kernel tree(s) are you wanting this to be applied to?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] KVM: x86/mmu: fix NULL pointer dereference on guest INVPCID
2022-05-24 15:22 ` Greg KH
@ 2022-05-24 15:27 ` Vegard Nossum
2022-05-24 15:35 ` Greg KH
0 siblings, 1 reply; 7+ messages in thread
From: Vegard Nossum @ 2022-05-24 15:27 UTC (permalink / raw)
To: Greg KH; +Cc: stable, Sean Christopherson, Paolo Bonzini, Yongkang Jia
On 5/24/22 17:22, Greg KH wrote:
> On Tue, May 24, 2022 at 05:11:18PM +0200, Vegard Nossum wrote:
>> From: Paolo Bonzini <pbonzini@redhat.com>
>>
>> commit 9f46c187e2e680ecd9de7983e4d081c3391acc76 upstream.
>>
>> With shadow paging enabled, the INVPCID instruction results in a call
>> to kvm_mmu_invpcid_gva. If INVPCID is executed with CR0.PG=0, the
>> invlpg callback is not set and the result is a NULL pointer dereference.
>> Fix it trivially by checking for mmu->invlpg before every call.
>>
>> There are other possibilities:
>>
>> - check for CR0.PG, because KVM (like all Intel processors after P5)
>> flushes guest TLB on CR0.PG changes so that INVPCID/INVLPG are a
>> nop with paging disabled
>>
>> - check for EFER.LMA, because KVM syncs and flushes when switching
>> MMU contexts outside of 64-bit mode
>>
>> All of these are tricky, go for the simple solution. This is CVE-2022-1789.
>>
>> Reported-by: Yongkang Jia <kangel@zju.edu.cn>
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>> [fix conflict due to missing b9e5603c2a3accbadfec570ac501a54431a6bdba]
>> Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
>> ---
>> arch/x86/kvm/mmu/mmu.c | 6 ++++--
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> What kernel tree(s) are you wanting this to be applied to?
I replied to the v5.17 email
(https://lore.kernel.org/stable/165314153515625@kroah.com/T/#u) and I've
only tested this on top of 5.17.9.
Is that generally enough to trigger attempts to automatically
cherry-pick it onto the older branches or should I test and submit for
the older ones as well?
How would you prefer to indicate the kernel tree(s) in the future?
Vegard
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] KVM: x86/mmu: fix NULL pointer dereference on guest INVPCID
2022-05-24 15:27 ` Vegard Nossum
@ 2022-05-24 15:35 ` Greg KH
2022-05-24 17:48 ` Vegard Nossum
0 siblings, 1 reply; 7+ messages in thread
From: Greg KH @ 2022-05-24 15:35 UTC (permalink / raw)
To: Vegard Nossum; +Cc: stable, Sean Christopherson, Paolo Bonzini, Yongkang Jia
On Tue, May 24, 2022 at 05:27:56PM +0200, Vegard Nossum wrote:
>
> On 5/24/22 17:22, Greg KH wrote:
> > On Tue, May 24, 2022 at 05:11:18PM +0200, Vegard Nossum wrote:
> >> From: Paolo Bonzini <pbonzini@redhat.com>
> >>
> >> commit 9f46c187e2e680ecd9de7983e4d081c3391acc76 upstream.
> >>
> >> With shadow paging enabled, the INVPCID instruction results in a call
> >> to kvm_mmu_invpcid_gva. If INVPCID is executed with CR0.PG=0, the
> >> invlpg callback is not set and the result is a NULL pointer dereference.
> >> Fix it trivially by checking for mmu->invlpg before every call.
> >>
> >> There are other possibilities:
> >>
> >> - check for CR0.PG, because KVM (like all Intel processors after P5)
> >> flushes guest TLB on CR0.PG changes so that INVPCID/INVLPG are a
> >> nop with paging disabled
> >>
> >> - check for EFER.LMA, because KVM syncs and flushes when switching
> >> MMU contexts outside of 64-bit mode
> >>
> >> All of these are tricky, go for the simple solution. This is CVE-2022-1789.
> >>
> >> Reported-by: Yongkang Jia <kangel@zju.edu.cn>
> >> Cc: stable@vger.kernel.org
> >> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> >> [fix conflict due to missing b9e5603c2a3accbadfec570ac501a54431a6bdba]
> >> Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
> >> ---
> >> arch/x86/kvm/mmu/mmu.c | 6 ++++--
> >> 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > What kernel tree(s) are you wanting this to be applied to?
>
> I replied to the v5.17 email
> (https://lore.kernel.org/stable/165314153515625@kroah.com/T/#u) and I've
> only tested this on top of 5.17.9.
>
> Is that generally enough to trigger attempts to automatically
> cherry-pick it onto the older branches or should I test and submit for
> the older ones as well?
You should test and submit for the older ones as well please.
> How would you prefer to indicate the kernel tree(s) in the future?
Just say so in the [PATCH 5.17.y] subject line, or in the signed-off-by
area or below the --- line.
Responding to the email and relying on the thread alone doesn't usually
work as the original message is long gone from my mailboxes, I can't
keep that old stuff cluttering up the place :)
thanks,
greg k-h
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] KVM: x86/mmu: fix NULL pointer dereference on guest INVPCID
2022-05-24 15:35 ` Greg KH
@ 2022-05-24 17:48 ` Vegard Nossum
2022-05-26 12:12 ` Greg KH
0 siblings, 1 reply; 7+ messages in thread
From: Vegard Nossum @ 2022-05-24 17:48 UTC (permalink / raw)
To: Greg KH; +Cc: stable, Sean Christopherson, Paolo Bonzini, Yongkang Jia
On 5/24/22 17:35, Greg KH wrote:
> On Tue, May 24, 2022 at 05:27:56PM +0200, Vegard Nossum wrote:
>>
>> On 5/24/22 17:22, Greg KH wrote:
>>> What kernel tree(s) are you wanting this to be applied to?
>>
>> I replied to the v5.17 email
>> (https://lore.kernel.org/stable/165314153515625@kroah.com/T/#u) and I've
>> only tested this on top of 5.17.9.
>>
>> Is that generally enough to trigger attempts to automatically
>> cherry-pick it onto the older branches or should I test and submit for
>> the older ones as well?
>
> You should test and submit for the older ones as well please.
Thanks, will do shortly.
>> How would you prefer to indicate the kernel tree(s) in the future?
>
> Just say so in the [PATCH 5.17.y] subject line, or in the signed-off-by
> area or below the --- line.
>
> Responding to the email and relying on the thread alone doesn't usually
> work as the original message is long gone from my mailboxes, I can't
> keep that old stuff cluttering up the place :)
If you want to make it easier for people to respond to these emails you
could change the FAILED: message to list specific git commands needed to
fix and submit. For this one in particular, you could for example make
it say:
git fetch
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/
linux-5.17.y
git checkout FETCH_HEAD
git cherry-pick -x 9f46c187e2e680ecd9de7983e4d081c3391acc76
# <resolve conflicts, build, test, etc.>
git send-email --subject-prefix 'PATCH 5.17.y' --to
'stable@vger.kernel.org' HEAD^..
Just an idea...
(And argh, just sent out for 5.15 and I put "PATCH 5.15" instead of
"PATCH 5.15.y" -- does that matter?)
Vegard
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] KVM: x86/mmu: fix NULL pointer dereference on guest INVPCID
2022-05-24 17:48 ` Vegard Nossum
@ 2022-05-26 12:12 ` Greg KH
0 siblings, 0 replies; 7+ messages in thread
From: Greg KH @ 2022-05-26 12:12 UTC (permalink / raw)
To: Vegard Nossum; +Cc: stable, Sean Christopherson, Paolo Bonzini, Yongkang Jia
On Tue, May 24, 2022 at 07:48:51PM +0200, Vegard Nossum wrote:
>
> On 5/24/22 17:35, Greg KH wrote:
> > On Tue, May 24, 2022 at 05:27:56PM +0200, Vegard Nossum wrote:
> >>
> >> On 5/24/22 17:22, Greg KH wrote:
> >>> What kernel tree(s) are you wanting this to be applied to?
> >>
> >> I replied to the v5.17 email
> >> (https://lore.kernel.org/stable/165314153515625@kroah.com/T/#u) and I've
> >> only tested this on top of 5.17.9.
> >>
> >> Is that generally enough to trigger attempts to automatically
> >> cherry-pick it onto the older branches or should I test and submit for
> >> the older ones as well?
> >
> > You should test and submit for the older ones as well please.
>
> Thanks, will do shortly.
>
> >> How would you prefer to indicate the kernel tree(s) in the future?
> >
> > Just say so in the [PATCH 5.17.y] subject line, or in the signed-off-by
> > area or below the --- line.
> >
> > Responding to the email and relying on the thread alone doesn't usually
> > work as the original message is long gone from my mailboxes, I can't
> > keep that old stuff cluttering up the place :)
>
> If you want to make it easier for people to respond to these emails you
> could change the FAILED: message to list specific git commands needed to
> fix and submit. For this one in particular, you could for example make
> it say:
>
> git fetch
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/
> linux-5.17.y
> git checkout FETCH_HEAD
> git cherry-pick -x 9f46c187e2e680ecd9de7983e4d081c3391acc76
> # <resolve conflicts, build, test, etc.>
> git send-email --subject-prefix 'PATCH 5.17.y' --to
> 'stable@vger.kernel.org' HEAD^..
>
> Just an idea...
That's a nice idea, I'll consider adding it to my scripts.
> (And argh, just sent out for 5.15 and I put "PATCH 5.15" instead of
> "PATCH 5.15.y" -- does that matter?)
No, not at all, all is good and now queued up, thanks.
greg k-h
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2022-05-26 12:13 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-05-21 13:58 FAILED: patch "[PATCH] KVM: x86/mmu: fix NULL pointer dereference on guest INVPCID" failed to apply to 5.17-stable tree gregkh
2022-05-24 15:11 ` [PATCH] KVM: x86/mmu: fix NULL pointer dereference on guest INVPCID Vegard Nossum
2022-05-24 15:22 ` Greg KH
2022-05-24 15:27 ` Vegard Nossum
2022-05-24 15:35 ` Greg KH
2022-05-24 17:48 ` Vegard Nossum
2022-05-26 12:12 ` Greg KH
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.