Bug 1221024 (CVE-2023-52514)

Summary: VUL-0: REJECTED: CVE-2023-52514: kernel: x86/reboot: VMCLEAR active VMCSes before emergency reboot
Product: [Novell Products] SUSE Security Incidents Reporter: SMASH SMASH <smash_bz>
Component: IncidentsAssignee: Security Team bot <security-team>
Status: RESOLVED INVALID QA Contact: Security Team bot <security-team>
Severity: Normal    
Priority: P3 - Medium CC: andrea.mattiazzo, jgross, mhocko, nik.borisov, osalvador, rfrohl
Version: unspecified   
Target Milestone: ---   
Hardware: Other   
OS: Other   
URL: https://smash.suse.de/issue/396063/
Whiteboard: CVSSv3.1:SUSE:CVE-2023-52514:5.5:(AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Found By: Security Response Team Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description SMASH SMASH 2024-03-06 08:04:42 UTC 
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.

References:
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-52514
https://git.kernel.org/stable/c/b23c83ad2c638420ec0608a9de354507c41bec29
https://www.cve.org/CVERecord?id=CVE-2023-52514
https://git.kernel.org/stable/c/1375d9600c38c231163de584656b07aef9a27b0d
https://git.kernel.org/stable/c/65edea77d7006140c6290e7f46009d75e02d3273
https://bugzilla.redhat.com/show_bug.cgi?id=2267803
Comment 5 Nikolay Borisov 2024-03-08 11:42:47 UTC 
I'd rate this as low severity issue that's not worth bothering, furthermore it's part of a larger series hardening the KVM code: 

https://lore.kernel.org/all/20230721201859.2307736-1-seanjc@google.com/

Ideally this should be judged by the virtualizatino people.
Comment 8 Jürgen Groß 2024-03-08 15:51:57 UTC 
If anything, this is a bug, but not a security issue.

There is no way an unprivileged user (VM or process) could trigger this issue, as they can't cause the host to reboot. In case they could, THAT would be a vulnerability.

So I'd say we can ignore it from the security POV.

BTW, the related upstream patch is part of SLE15-SP6.
Comment 11 Jürgen Groß 2024-03-08 18:48:15 UTC 
You can Cc me.
Comment 13 Oscar Salvador 2024-04-16 04:37:07 UTC 
No valid CVE.
Back to sec-team.
Comment 14 Andrea Mattiazzo 2024-05-23 15:57:58 UTC 
All done, closing.