Message ID | 20221103141351.50662-5-mlevitsk@redhat.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp560707wru; Thu, 3 Nov 2022 07:16:43 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6Z1bMN3YL9Kq71B+OoAI2YlnB2tKDePmTVUSo4ZuEp7NKiB5unNzWDxcfWnkfaV+0ktTNh X-Received: by 2002:a63:914b:0:b0:46e:dbd5:ae15 with SMTP id l72-20020a63914b000000b0046edbd5ae15mr26504017pge.94.1667485002807; Thu, 03 Nov 2022 07:16:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1667485002; cv=none; d=google.com; s=arc-20160816; b=j62iklPbBMmw6QAnuSUVVqf20uQjIGEEkTXCxb/PchsDBLweyI79D3NenSo1uH5nO4 1NxuZZjh1FHuqjQ+917rrEkX908KbyjaFC+shLyTmDhERaQMbOfvexjVFXrUtSmo5DsP xj6Q2zxjN+fAI6Fiu2UXkEpntDH24bKliWyPYtMV73lvhVkjzgm1SXQLgtrLWmDTLVur gGAI6Tkt8Vca9bN7kjjOKg3jNHEtC329L/HyL1y6e7etgXAV+OL+jQhSjas6lcY6Qiio Xz7QX8xP5sLB8Nfd58BqWtWBI+UUPpJC6dqY7w6h2MuAbUBAYggRGPsRuD+vlpwlitik df7A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=5Rmr0NPOPytRRHk5QfeeqyFTJ7brcQ8/Uu01aFjhZlA=; b=OtzrijjATIU7G3AQPvGxSI25xsebZ73cJr/6EYgn4AT5Lr0fYqt/oeGAfi6Ju3nCLU 4p9f8ASS6tSOet2EfboSFPrr8SZsO8FvXSypnHFqrGE2q0/p/xzPE3IAZBwtf0bF6GU6 IIQ7820G/+054QeoUGcc3kDVImTKh+NpEj8dnDbuLtKncN+g88dEI9chgIPrIy5l8yLT WrJY+qpCKWh/MBIA+/cgqw602AIbkGNwEUt9rL4K0UlSll2hdqDyo4cIbnVJrcruwrDp HcPOWULcyz5cXh+xMP4+n/Vf2zM92/B/mQ4R3M5AWS8249rBNtKkJ38x79NJXt/SF2KN nYIQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=L+nxbdji; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q25-20020a635c19000000b0046b1091d76bsi1356614pgb.416.2022.11.03.07.16.29; Thu, 03 Nov 2022 07:16:42 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=L+nxbdji; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231700AbiKCOPi (ORCPT <rfc822;yves.mi.zy@gmail.com> + 99 others); Thu, 3 Nov 2022 10:15:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35622 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231545AbiKCOPR (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 3 Nov 2022 10:15:17 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0605B2723 for <linux-kernel@vger.kernel.org>; Thu, 3 Nov 2022 07:14:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1667484857; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5Rmr0NPOPytRRHk5QfeeqyFTJ7brcQ8/Uu01aFjhZlA=; b=L+nxbdjiHtrFF4eD5yQw1sH555zDz8VqPXi/84pwCaHrpCDurDaskJwOw+7qzFRfi9HUU7 naobVO0ZAj3Q10aTEb55jTJwKgZEjZW4rruvJbmwM9b3JYB21+28etHkEmByW2DenNcP46 /c93mel0BD36BfIi2fxvfarlYpDKcGQ= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-158-8QSbxQGbMy2_stjOx5gJeA-1; Thu, 03 Nov 2022 10:14:14 -0400 X-MC-Unique: 8QSbxQGbMy2_stjOx5gJeA-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id DBBFD1C08780; Thu, 3 Nov 2022 14:14:12 +0000 (UTC) Received: from amdlaptop.tlv.redhat.com (dhcp-4-238.tlv.redhat.com [10.35.4.238]) by smtp.corp.redhat.com (Postfix) with ESMTP id 48C6B40C6EC3; Thu, 3 Nov 2022 14:14:08 +0000 (UTC) From: Maxim Levitsky <mlevitsk@redhat.com> To: kvm@vger.kernel.org Cc: Paolo Bonzini <pbonzini@redhat.com>, Thomas Gleixner <tglx@linutronix.de>, linux-kernel@vger.kernel.org, Chenyi Qiang <chenyi.qiang@intel.com>, Yang Zhong <yang.zhong@intel.com>, x86@kernel.org, Shuah Khan <shuah@kernel.org>, Dave Hansen <dave.hansen@linux.intel.com>, "H. Peter Anvin" <hpa@zytor.com>, Maxim Levitsky <mlevitsk@redhat.com>, Colton Lewis <coltonlewis@google.com>, Borislav Petkov <bp@alien8.de>, Peter Xu <peterx@redhat.com>, Sean Christopherson <seanjc@google.com>, Jim Mattson <jmattson@google.com>, linux-kselftest@vger.kernel.org, Ingo Molnar <mingo@redhat.com>, Wei Wang <wei.w.wang@intel.com>, David Matlack <dmatlack@google.com>, stable@vger.kernel.org Subject: [PATCH v2 4/9] KVM: x86: forcibly leave nested mode on vCPU reset Date: Thu, 3 Nov 2022 16:13:46 +0200 Message-Id: <20221103141351.50662-5-mlevitsk@redhat.com> In-Reply-To: <20221103141351.50662-1-mlevitsk@redhat.com> References: <20221103141351.50662-1-mlevitsk@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.1 on 10.11.54.2 X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1748484754679171685?= X-GMAIL-MSGID: =?utf-8?q?1748484754679171685?= |
Series |
nSVM: Security and correctness fixes
|
|
Commit Message
Maxim Levitsky
Nov. 3, 2022, 2:13 p.m. UTC
While not obivous, kvm_vcpu_reset() leaves the nested mode by clearing
'vcpu->arch.hflags' but it does so without all the required housekeeping.
On SVM, it is possible to have a vCPU reset while in guest mode because
unlike VMX, on SVM, INIT's are not latched in SVM non root mode and in
addition to that L1 doesn't have to intercept triple fault, which should
also trigger L1's reset if happens in L2 while L1 didn't intercept it.
If one of the above conditions happen, KVM will continue to use vmcb02
while not having in the guest mode.
Later the IA32_EFER will be cleared which will lead to freeing of the
nested guest state which will (correctly) free the vmcb02, but since
KVM still uses it (incorrectly) this will lead to a use after free
and kernel crash.
This issue is assigned CVE-2022-3344
Cc: stable@vger.kernel.org
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
---
arch/x86/kvm/x86.c | 10 ++++++++++
1 file changed, 10 insertions(+)
Comments
On 03/11/2022 14:13, Maxim Levitsky wrote: > While not obivous, kvm_vcpu_reset() leaves the nested mode by clearing > 'vcpu->arch.hflags' but it does so without all the required housekeeping. > > On SVM, it is possible to have a vCPU reset while in guest mode because > unlike VMX, on SVM, INIT's are not latched in SVM non root mode and in > addition to that L1 doesn't have to intercept triple fault, which should > also trigger L1's reset if happens in L2 while L1 didn't intercept it. > > If one of the above conditions happen, KVM will continue to use vmcb02 > while not having in the guest mode. "having" is the wrong word here - maybe "not having in the" -> "not being in" ? > > Later the IA32_EFER will be cleared which will lead to freeing of the > nested guest state which will (correctly) free the vmcb02, but since > KVM still uses it (incorrectly) this will lead to a use after free > and kernel crash. > > This issue is assigned CVE-2022-3344 > > Cc: stable@vger.kernel.org > Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Reviewed-by: Liam Merwick <liam.merwick@oracle.com> > --- > arch/x86/kvm/x86.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index 316ab1d5317f92..3fd900504e683b 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -11694,8 +11694,18 @@ void kvm_vcpu_reset(struct kvm_vcpu *vcpu, bool init_event) > WARN_ON_ONCE(!init_event && > (old_cr0 || kvm_read_cr3(vcpu) || kvm_read_cr4(vcpu))); > > + /* > + * SVM doesn't unconditionally VM-Exit on INIT and SHUTDOWN, thus it's > + * possible to INIT the vCPU while L2 is active. Force the vCPU back > + * into L1 as EFER.SVME is cleared on INIT (along with all other EFER > + * bits), i.e. virtualization is disabled. > + */ > + if (is_guest_mode(vcpu)) > + kvm_leave_nested(vcpu); > + > kvm_lapic_reset(vcpu, init_event); > > + WARN_ON_ONCE(is_guest_mode(vcpu) || is_smm(vcpu)); > vcpu->arch.hflags = 0; > > vcpu->arch.smi_pending = 0;
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 316ab1d5317f92..3fd900504e683b 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -11694,8 +11694,18 @@ void kvm_vcpu_reset(struct kvm_vcpu *vcpu, bool init_event) WARN_ON_ONCE(!init_event && (old_cr0 || kvm_read_cr3(vcpu) || kvm_read_cr4(vcpu))); + /* + * SVM doesn't unconditionally VM-Exit on INIT and SHUTDOWN, thus it's + * possible to INIT the vCPU while L2 is active. Force the vCPU back + * into L1 as EFER.SVME is cleared on INIT (along with all other EFER + * bits), i.e. virtualization is disabled. + */ + if (is_guest_mode(vcpu)) + kvm_leave_nested(vcpu); + kvm_lapic_reset(vcpu, init_event); + WARN_ON_ONCE(is_guest_mode(vcpu) || is_smm(vcpu)); vcpu->arch.hflags = 0; vcpu->arch.smi_pending = 0;