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