All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Vegard Nossum <vegard.nossum@oracle.com>
Cc: stable@vger.kernel.org, Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Yongkang Jia <kangel@zju.edu.cn>
Subject: Re: [PATCH] KVM: x86/mmu: fix NULL pointer dereference on guest INVPCID
Date: Tue, 24 May 2022 17:35:36 +0200	[thread overview]
Message-ID: <Yoz7SFl7dIb65kPw@kroah.com> (raw)
In-Reply-To: <e4127ebb-c589-ac2c-e77a-6c56a9c8fbc4@oracle.com>

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

  reply	other threads:[~2022-05-24 15:35 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2022-05-24 17:48         ` Vegard Nossum
2022-05-26 12:12           ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Yoz7SFl7dIb65kPw@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=kangel@zju.edu.cn \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.com \
    --cc=stable@vger.kernel.org \
    --cc=vegard.nossum@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.