CVE-2024-58083

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: Explicitly verify target vCPU is online in kvm_get_vcpu()<br /> <br /> Explicitly verify the target vCPU is fully online _prior_ to clamping the<br /> index in kvm_get_vcpu(). If the index is "bad", the nospec clamping will<br /> generate &amp;#39;0&amp;#39;, i.e. KVM will return vCPU0 instead of NULL.<br /> <br /> In practice, the bug is unlikely to cause problems, as it will only come<br /> into play if userspace or the guest is buggy or misbehaving, e.g. KVM may<br /> send interrupts to vCPU0 instead of dropping them on the floor.<br /> <br /> However, returning vCPU0 when it shouldn&amp;#39;t exist per online_vcpus is<br /> problematic now that KVM uses an xarray for the vCPUs array, as KVM needs<br /> to insert into the xarray before publishing the vCPU to userspace (see<br /> commit c5b077549136 ("KVM: Convert the kvm-&gt;vcpus array to a xarray")),<br /> i.e. before vCPU creation is guaranteed to succeed.<br /> <br /> As a result, incorrectly providing access to vCPU0 will trigger a<br /> use-after-free if vCPU0 is dereferenced and kvm_vm_ioctl_create_vcpu()<br /> bails out of vCPU creation due to an error and frees vCPU0. Commit<br /> afb2acb2e3a3 ("KVM: Fix vcpu_array[0] races") papered over that issue, but<br /> in doing so introduced an unsolvable teardown conundrum. Preventing<br /> accesses to vCPU0 before it&amp;#39;s fully online will allow reverting commit<br /> afb2acb2e3a3, without re-introducing the vcpu_array[0] UAF race.