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

PATCH In review [email protected] 2 participants 7 messages May 21, 2022 – May 26, 2022

Subsystems (3)

Stable branch x86 KVM x86

lore

Share & tools

lore

[email protected]

author maintainer

2022-05-21 13:59 UTC #0 lore raw

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 <[email protected]>.

thanks,

greg k-h

------------------ original commit in Linus's tree ------------------

From 9f46c187e2e680ecd9de7983e4d081c3391acc76 Mon Sep 17 00:00:00 2001
From: Paolo Bonzini <[email protected]>
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 <[email protected]>

Cc [email protected]

Signed-off-by Paolo Bonzini <[email protected]>

arch/x86/kvm/mmu/mmu.c +4 -2

index 56ebc4fb7f91..45e1573f8f1d 100644
@@ -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;
 		}
 	}

Vegard Nossum

2022-05-24 15:12 UTC #1 lore raw

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

From: Paolo Bonzini <[email protected]>

commit 9f46c187e2e680ecd9de7983e4d081c3391acc76 upstream.

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 <[email protected]>

Cc [email protected]

Signed-off-by Paolo Bonzini <[email protected]>

[fix conflict due to missing b9e5603c2a3accbadfec570ac501a54431a6bdba]

Signed-off-by Vegard Nossum <[email protected]>

---
 arch/x86/kvm/mmu/mmu.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

arch/x86/kvm/mmu/mmu.c +4 -2

index e7cd16e1e0a0b..ff65584c7e5f4 100644
@@ -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;
 		}
 	}

Signature · 1 line

2.35.1.46.g38062e73e0

Greg KH

author maintainer

2022-05-24 15:23 UTC #2 lore raw

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

Quoted 20 lines · Vegard Nossum

From: Paolo Bonzini <[email protected]>
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.

Quoted 8 lines

Reported-by Yongkang Jia <[email protected]>
Cc [email protected]
Signed-off-by Paolo Bonzini <[email protected]>
[fix conflict due to missing b9e5603c2a3accbadfec570ac501a54431a6bdba]
Signed-off-by Vegard Nossum <[email protected]>
---
 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

Vegard Nossum

2022-05-24 15:28 UTC #3 lore raw

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

Quoted 30 lines · Greg KH

Quoted 20 lines · Vegard Nossum
From: Paolo Bonzini <[email protected]>
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.
Quoted 8 lines
Reported-by Yongkang Jia <[email protected]>
Cc [email protected]
Signed-off-by Paolo Bonzini <[email protected]>
[fix conflict due to missing b9e5603c2a3accbadfec570ac501a54431a6bdba]
Signed-off-by Vegard Nossum <[email protected]>
---
 arch/x86/kvm/mmu/mmu.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

Quoted 1 line

What kernel tree(s) are you wanting this to be applied to?

I replied to the v5.17 email
(https://lore.kernel.org/stable/[email protected]/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

Greg KH

author maintainer

2022-05-24 15:35 UTC #4 lore raw

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

Quoted 34 lines · Vegard Nossum

Quoted 30 lines · Greg KH
Quoted 20 lines · Vegard Nossum
From: Paolo Bonzini <[email protected]>
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.
Quoted 8 lines
Reported-by Yongkang Jia <[email protected]>
Cc [email protected]
Signed-off-by Paolo Bonzini <[email protected]>
[fix conflict due to missing b9e5603c2a3accbadfec570ac501a54431a6bdba]
Signed-off-by Vegard Nossum <[email protected]>
---
 arch/x86/kvm/mmu/mmu.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)
Quoted 1 line
What kernel tree(s) are you wanting this to be applied to?

Quoted 7 lines

I replied to the v5.17 email
(https://lore.kernel.org/stable/[email protected]/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.

Quoted 1 line

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

Vegard Nossum

2022-05-24 17:49 UTC #5 lore raw

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

Quoted 9 lines · Greg KH

Quoted 8 lines · Vegard Nossum
Quoted 1 line · Greg KH
What kernel tree(s) are you wanting this to be applied to?
I replied to the v5.17 email
(https://lore.kernel.org/stable/[email protected]/T/#u) and I've only tested this on top of 5.17.9.

Quoted 5 lines

Quoted 3 lines
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.

Quoted 8 lines

Quoted 1 line
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 '[email protected]' 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

Greg KH

author maintainer

2022-05-26 12:13 UTC #6 lore raw

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

Quoted 42 lines · Vegard Nossum

Quoted 9 lines · Greg KH
Quoted 8 lines · Vegard Nossum
Quoted 1 line · Greg KH
What kernel tree(s) are you wanting this to be applied to?
I replied to the v5.17 email
(https://lore.kernel.org/stable/[email protected]/T/#u) and I've only tested this on top of 5.17.9.
Quoted 5 lines
Quoted 3 lines
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.
Quoted 8 lines
Quoted 1 line
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 '[email protected]' HEAD^..

Quoted 1 line

Just an idea...

That's a nice idea, I'll consider adding it to my scripts.

Quoted 2 lines

(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