FAILED: patch "[PATCH] KVM: x86/mmu: fix NULL pointer dereference on guest INVPCID" failed to apply to 5.17-stable tree

FAILED: patch "[PATCH] KVM: x86/mmu: fix NULL pointer dereference on guest INVPCID" failed to apply to 5.17-stable tree

[gregkh]

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;
 		}
 	}

[PATCH] KVM: x86/mmu: fix NULL pointer dereference on guest INVPCID

[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

Re: [PATCH] KVM: x86/mmu: fix NULL pointer dereference on guest INVPCID

[Greg KH]

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

Re: [PATCH] KVM: x86/mmu: fix NULL pointer dereference on guest INVPCID

[Vegard Nossum]

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

Re: [PATCH] KVM: x86/mmu: fix NULL pointer dereference on guest INVPCID

[Greg KH]

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

Re: [PATCH] KVM: x86/mmu: fix NULL pointer dereference on guest INVPCID

[Vegard Nossum]

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

Re: [PATCH] KVM: x86/mmu: fix NULL pointer dereference on guest INVPCID

[Greg KH]

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