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
On Mon, 11 Mar 2024, Michal Hocko wrote:
> 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?
Thanks for reporting.
If Sean and/or Paolo agree, we can revoke the CVE for you.
--
Lee Jones [李琼斯]
On Mon, Mar 11, 2024, Lee Jones wrote:
> On Mon, 11 Mar 2024, Michal Hocko wrote:
>
> > 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.
And not just any reboot either, this only comes into play with something like
`reboot -f`. Not to mention the impact of the bug is ridiculously theroetical
(I didn't tag the patch for stable@ for a reason).
> > Or am I missing something?
>
> Thanks for reporting.
>
> If Sean and/or Paolo agree, we can revoke the CVE for you.
Please do.
On Mon, 11 Mar 2024, Sean Christopherson wrote:
> On Mon, Mar 11, 2024, Lee Jones wrote:
> > On Mon, 11 Mar 2024, Michal Hocko wrote:
> >
> > > 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.
>
> And not just any reboot either, this only comes into play with something like
> `reboot -f`. Not to mention the impact of the bug is ridiculously theroetical
> (I didn't tag the patch for stable@ for a reason).
>
> > > Or am I missing something?
> >
> > Thanks for reporting.
> >
> > If Sean and/or Paolo agree, we can revoke the CVE for you.
>
> Please do.
No problem. All done for you:
https://lore.kernel.org/all/[email protected]/
Thanks again for the report.
--
Lee Jones [李琼斯]