Bugzilla – Bug 1221024
VUL-0: REJECTED: CVE-2023-52514: kernel: x86/reboot: VMCLEAR active VMCSes before emergency reboot
Last modified: 2024-05-23 15:57:58 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
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.
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.
You can Cc me.
REJECTED: https://lore.kernel.org/linux-cve-announce/20240311161318.1290374-2-lee@kernel.org/T/#u
No valid CVE. Back to sec-team.
All done, closing.