CVE-2026-74607: Linux kernel · KVM: SVM: Serialize accesses to the owner and mirror list with separate lock
Source GCVE Database
Not known to be exploited · CVSS 8.8 High.
Data as of 26 Oct 2026, 17:16 UTC
- EPSS
- 0.1% chance of exploitation in 30 days – higher than 2% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:HExploitation evidence
Disclosed: evidence found.
CVE published 22 Aug 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.
Description
In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Serialize accesses to the owner and mirror list with separate lock Interaction between KVM_CAP_VM_MOVE_ENC_CONTEXT_FROM and KVM_CAP_VM_COPY_ENC_CONTEXT_FROM can cause two separate issues: - in sev_migrate_from(), when the destination KVM is a mirror, the mirror entry is moved from the source's list to the owner's mirror_vms list, without holding the owner's lock unlike other writers of the owner's mirror list (sev_vm_copy_enc_context_from(), sev_vm_destroy()). A concurrent COPY or destroy can race with sev_migrate_from() and corrupt the list. - In sev_vm_destroy(), the *owner* is still active and could receive concurrently a KVM_CAP_VM_MOVE_ENC_CONTEXT_FROM that causes sev->enc_context_owner to change. In this case the incorrect VM receives kvm_put_kvm(). The second issue needs particular care because the owner could disappear altogether (even though the race window is impossibly small) between reading it and locking it. There is thus no way to perform the checks under the owner lock without putting struct kvm under SLAB_TYPESAFE_BY_RCU (which would allow kvm_get_kvm_safe() under RCU critical section). It is much simpler to just use a global lock, since the critical sections are so small and the new lock is always a leaf lock.
References
- nvd.nist.gov/vuln/detail/CVE-2026-74607 (opens in a new tab)
- git.kernel.org/stable/c/1d78d33275ef2a16c6d080910b291d0a97a0e613 (opens in a new tab)
- git.kernel.org/stable/c/28afde1edbd8b20058cbf4d75fb57876471ec334 (opens in a new tab)
- git.kernel.org/stable/c/328ab4fabe05af004d886659f8744076e320ddce (opens in a new tab)
- git.kernel.org/stable/c/47976eaaf0a4eb46dade48b3246779090db9e3ec (opens in a new tab)
- git.kernel.org/stable/c/7943ec3a6d0e7e0a2eb4943300bce089ac3e8c3e (opens in a new tab)
- git.kernel.org/stable/c/d728baba0f20e49439fc7831bf3e4e7dee82161a (opens in a new tab)