Received-SPF: pass (google.com: domain of linux-kernel+bounces-98701-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Mon, 11 Mar 2024 11:32:49 +0100
From: Michal Hocko <mhocko@suse.com>
To: cve@kernel.org, linux-kernel@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Juergen Gross <jgross@suse.com>,
	Sean Christopherson <seanjc@google.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>
Subject: Re: CVE-2023-52514: x86/reboot: VMCLEAR active VMCSes before
 emergency reboot
Message-ID: <Ze7d0YCDKdu_LJWc@tiehlicka>
References: <2024030251-CVE-2023-52514-c93d@gregkh>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2024030251-CVE-2023-52514-c93d@gregkh>

On Sat 02-03-24 22:52:59, Greg KH wrote:
> Description
> ===========
> 
> In the Linux kernel, the following vulnerability has been resolved:
> 
> x86/reboot: VMCLEAR active VMCSes before emergency reboot
> 
> VMCLEAR active VMCSes before any emergency reboot, not just if the kernel
> may kexec into a new kernel after a crash.  Per Intel's SDM, the VMX
> architecture doesn't require the CPU to flush the VMCS cache on INIT.  If
> an emergency reboot doesn't RESET CPUs, cached VMCSes could theoretically
> be kept and only be written back to memory after the new kernel is booted,
> i.e. could effectively corrupt memory after reboot.
> 
> Opportunistically remove the setting of the global pointer to NULL to make
> checkpatch happy.
> 
> The Linux kernel CVE team has assigned CVE-2023-52514 to this issue.

I do not really see the security aspect of this fix. Guests systems
shouldn't be able to trigger host reboot nor any untrusted entity should
on the host either or this would be a serious security hole.

Or am I missing something?
-- 
Michal Hocko
SUSE Labs