linux-kernel - Re: CVE-2023-52514: x86/reboot: VMCLEAR active VMCSes before emergency reboot

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date: Mon, 11 Mar 2024 11:32:49 +0100
From: Michal Hocko <mhocko@...e.com>
To: cve@...nel.org, linux-kernel@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Juergen Gross <jgross@...e.com>,
	Sean Christopherson <seanjc@...gle.com>,
	Andrew Cooper <Andrew.Cooper3@...rix.com>
Subject: Re: CVE-2023-52514: x86/reboot: VMCLEAR active VMCSes before
 emergency reboot

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