CVE-2022-49559

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86: Drop WARNs that assert a triple fault never "escapes" from L2<br /> <br /> Remove WARNs that sanity check that KVM never lets a triple fault for L2<br /> escape and incorrectly end up in L1. In normal operation, the sanity<br /> check is perfectly valid, but it incorrectly assumes that it&amp;#39;s impossible<br /> for userspace to induce KVM_REQ_TRIPLE_FAULT without bouncing through<br /> KVM_RUN (which guarantees kvm_check_nested_state() will see and handle<br /> the triple fault).<br /> <br /> The WARN can currently be triggered if userspace injects a machine check<br /> while L2 is active and CR4.MCE=0. And a future fix to allow save/restore<br /> of KVM_REQ_TRIPLE_FAULT, e.g. so that a synthesized triple fault isn&amp;#39;t<br /> lost on migration, will make it trivially easy for userspace to trigger<br /> the WARN.<br /> <br /> Clearing KVM_REQ_TRIPLE_FAULT when forcibly leaving guest mode is<br /> tempting, but wrong, especially if/when the request is saved/restored,<br /> e.g. if userspace restores events (including a triple fault) and then<br /> restores nested state (which may forcibly leave guest mode). Ignoring<br /> the fact that KVM doesn&amp;#39;t currently provide the necessary APIs, it&amp;#39;s<br /> userspace&amp;#39;s responsibility to manage pending events during save/restore.<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 7 PID: 1399 at arch/x86/kvm/vmx/nested.c:4522 nested_vmx_vmexit+0x7fe/0xd90 [kvm_intel]<br /> Modules linked in: kvm_intel kvm irqbypass<br /> CPU: 7 PID: 1399 Comm: state_test Not tainted 5.17.0-rc3+ #808<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015<br /> RIP: 0010:nested_vmx_vmexit+0x7fe/0xd90 [kvm_intel]<br /> Call Trace:<br /> <br /> vmx_leave_nested+0x30/0x40 [kvm_intel]<br /> vmx_set_nested_state+0xca/0x3e0 [kvm_intel]<br /> kvm_arch_vcpu_ioctl+0xf49/0x13e0 [kvm]<br /> kvm_vcpu_ioctl+0x4b9/0x660 [kvm]<br /> __x64_sys_ioctl+0x83/0xb0<br /> do_syscall_64+0x3b/0xc0<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> ---[ end trace 0000000000000000 ]---