GHSA-V5CV-JRWX-XXRG
Vulnerability from github – Published: 2026-08-22 18:30 – Updated: 2026-08-25 06:31In 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.
{
"affected": [],
"aliases": [
"CVE-2026-74607"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-22T16:16:33Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: SVM: Serialize accesses to the owner and mirror list with separate lock\n\nInteraction between KVM_CAP_VM_MOVE_ENC_CONTEXT_FROM and\nKVM_CAP_VM_COPY_ENC_CONTEXT_FROM can cause two separate issues:\n\n- in sev_migrate_from(), when the destination KVM is a mirror, the mirror\n entry is moved from the source\u0027s list to the owner\u0027s mirror_vms list,\n without holding the owner\u0027s lock unlike other writers of the owner\u0027s\n mirror list (sev_vm_copy_enc_context_from(), sev_vm_destroy()).\n A concurrent COPY or destroy can race with sev_migrate_from() and\n corrupt the list.\n\n- In sev_vm_destroy(), the *owner* is still active and could receive\n concurrently a KVM_CAP_VM_MOVE_ENC_CONTEXT_FROM that causes\n sev-\u003eenc_context_owner to change. In this case the incorrect VM\n receives kvm_put_kvm().\n\nThe second issue needs particular care because the owner could disappear\naltogether (even though the race window is impossibly small) between\nreading it and locking it. There is thus no way to perform the checks\nunder the owner lock without putting struct kvm under SLAB_TYPESAFE_BY_RCU\n(which would allow kvm_get_kvm_safe() under RCU critical section).\n\nIt is much simpler to just use a global lock, since the critical\nsections are so small and the new lock is always a leaf lock.",
"id": "GHSA-v5cv-jrwx-xxrg",
"modified": "2026-08-25T06:31:22Z",
"published": "2026-08-22T18:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74607"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1d78d33275ef2a16c6d080910b291d0a97a0e613"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/28afde1edbd8b20058cbf4d75fb57876471ec334"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/328ab4fabe05af004d886659f8744076e320ddce"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/47976eaaf0a4eb46dade48b3246779090db9e3ec"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7943ec3a6d0e7e0a2eb4943300bce089ac3e8c3e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d728baba0f20e49439fc7831bf3e4e7dee82161a"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.