FAILED: patch "[PATCH] KVM: x86/mmu: fix NULL pointer dereference on guest INVPCID" failed to apply to 5.17-stable tree
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; } }
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; } }
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
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
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
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
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
linux-stable-mirror@lists.linaro.org
-
Greg KH -
gregkh＠linuxfoundation.org
-
Vegard Nossum