CVE-2024-58083: KVM: Explicitly verify target vCPU is online in kvm_get_vcpu()
In the Linux kernel, the following vulnerability has been resolved:
KVM: Explicitly verify target vCPU is online in kvm_get_vcpu()
Explicitly verify the target vCPU is fully online _prior_ to clamping the
index in kvm_get_vcpu(). If the index is "bad", the nospec clamping will
generate '0', i.e. KVM will return vCPU0 instead of NULL.
In practice, the bug is unlikely to cause problems, as it will only come
into play if userspace or the guest is buggy or misbehaving, e.g. KVM may
send interrupts to vCPU0 instead of dropping them on the floor.
However, returning vCPU0 when it shouldn't exist per online_vcpus is
problematic now that KVM uses an xarray for the vCPUs array, as KVM needs
to insert into the xarray before publishing the vCPU to userspace (see
commit c5b077549136 ("KVM: Convert the kvm->vcpus array to a xarray")),
i.e. before vCPU creation is guaranteed to succeed.
As a result, incorrectly providing access to vCPU0 will trigger a
use-after-free if vCPU0 is dereferenced and kvm_vm_ioctl_create_vcpu()
bails out of vCPU creation due to an error and frees vCPU0. Commit
afb2acb2e3a3 ("KVM: Fix vcpu_array[0] races") papered over that issue, but
in doing so introduced an unsolvable teardown conundrum. Preventing
accesses to vCPU0 before it's fully online will allow reverting commit
afb2acb2e3a3, without re-introducing the vcpu_array[0] UAF race.
Security readout for executives and security teams
Plain-English summary
CVE-2024-58083 is a Linux KVM kernel flaw where an invalid virtual CPU reference can incorrectly resolve to vCPU0. Under error handling during vCPU creation, this can lead to use-after-free memory access. It is high severity because successful abuse could affect confidentiality, integrity, and availability, but it requires local privileges.
Executive priority
Treat this as a scheduled high-priority kernel update for virtualization infrastructure, not an emergency internet-facing incident. Accelerate patching where KVM hosts serve multiple users or tenants. Current provided evidence does not show active exploitation.
Technical view
KVM’s kvm_get_vcpu() failed to verify that the target vCPU was online before nospec index clamping. A bad index could return vCPU0 instead of NULL. With the xarray vCPU storage path, early access to vCPU0 during failed creation can trigger CWE-416 use-after-free behavior.
Likely exposure
Linux systems using KVM virtualization on affected kernel versions or vendor backports are the relevant exposure. Priority is highest for shared virtualization hosts, cloud nodes, CI runners, and systems where untrusted local users or guests can reach KVM interfaces. The provided data does not identify non-Linux products.
Exploitation context
The CVE record says the bug is unlikely to cause problems unless userspace or a guest is buggy or misbehaving. CVSS marks it local, low complexity, low privilege, and no user interaction. KEV is false in the source bundle, so there is no provided evidence of active exploitation.
Researcher notes
The core issue is incorrect vCPU lookup semantics before online_vcpus validation, interacting with xarray-backed vCPU publication and failed creation cleanup. The source bundle references multiple stable kernel commits and Debian LTS advisories, but does not provide exploit evidence or a standalone workaround.
Mitigation direction
Apply Linux kernel or distribution security updates that include the referenced KVM stable fixes.
Follow Debian LTS or your Linux vendor advisory for exact package versions.
Prioritize KVM hosts with shared tenants or untrusted local users.
Reboot into the updated kernel after patching.
If patch timing is blocked, review vendor guidance for temporary risk reduction.
Validation and detection
Inventory Linux kernel versions across KVM-capable hosts.
Confirm whether KVM is enabled or used for virtualization workloads.
Compare running kernels against vendor advisories and the CVE record.
Verify updated hosts have actually booted the fixed kernel.
Check vulnerability scanners for CVE-2024-58083 coverage and false positives.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-416: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
2ADP providers
11Source links
SSVC decision data
CISA-ADPCISA Coordinator
Timestamp
Version
2.0.3
Exploitation: noneAutomatable: noTechnical Impact: total
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-416 · source CWE mapping
Use After Free
Use After Free represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.