GHSA-7FQ4-85X5-74RC
Vulnerability from github – Published: 2025-02-27 21:32 – Updated: 2025-02-27 21:32In the Linux kernel, the following vulnerability has been resolved:
KVM: x86/mmu: Zap all roots when unmapping gfn range in TDP MMU
Zap both valid and invalid roots when zapping/unmapping a gfn range, as KVM must ensure it holds no references to the freed page after returning from the unmap operation. Most notably, the TDP MMU doesn't zap invalid roots in mmu_notifier callbacks. This leads to use-after-free and other issues if the mmu_notifier runs to completion while an invalid root zapper yields as KVM fails to honor the requirement that there must be no references to the page after the mmu_notifier returns.
The bug is most easily reproduced by hacking KVM to cause a collision between set_nx_huge_pages() and kvm_mmu_notifier_release(), but the bug exists between kvm_mmu_notifier_invalidate_range_start() and memslot updates as well. Invalidating a root ensures pages aren't accessible by the guest, and KVM won't read or write page data itself, but KVM will trigger e.g. kvm_set_pfn_dirty() when zapping SPTEs, and thus completing a zap of an invalid root after the mmu_notifier returns is fatal.
WARNING: CPU: 24 PID: 1496 at arch/x86/kvm/../../../virt/kvm/kvm_main.c:173 [kvm] RIP: 0010:kvm_is_zone_device_pfn+0x96/0xa0 [kvm] Call Trace: kvm_set_pfn_dirty+0xa8/0xe0 [kvm] __handle_changed_spte+0x2ab/0x5e0 [kvm] __handle_changed_spte+0x2ab/0x5e0 [kvm] __handle_changed_spte+0x2ab/0x5e0 [kvm] zap_gfn_range+0x1f3/0x310 [kvm] kvm_tdp_mmu_zap_invalidated_roots+0x50/0x90 [kvm] kvm_mmu_zap_all_fast+0x177/0x1a0 [kvm] set_nx_huge_pages+0xb4/0x190 [kvm] param_attr_store+0x70/0x100 module_attr_store+0x19/0x30 kernfs_fop_write_iter+0x119/0x1b0 new_sync_write+0x11c/0x1b0 vfs_write+0x1cc/0x270 ksys_write+0x5f/0xe0 do_syscall_64+0x38/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae
{
"affected": [],
"aliases": [
"CVE-2021-47639"
],
"database_specific": {
"cwe_ids": [
"CWE-416"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T06:37:05Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86/mmu: Zap _all_ roots when unmapping gfn range in TDP MMU\n\nZap both valid and invalid roots when zapping/unmapping a gfn range, as\nKVM must ensure it holds no references to the freed page after returning\nfrom the unmap operation. Most notably, the TDP MMU doesn\u0027t zap invalid\nroots in mmu_notifier callbacks. This leads to use-after-free and other\nissues if the mmu_notifier runs to completion while an invalid root\nzapper yields as KVM fails to honor the requirement that there must be\n_no_ references to the page after the mmu_notifier returns.\n\nThe bug is most easily reproduced by hacking KVM to cause a collision\nbetween set_nx_huge_pages() and kvm_mmu_notifier_release(), but the bug\nexists between kvm_mmu_notifier_invalidate_range_start() and memslot\nupdates as well. Invalidating a root ensures pages aren\u0027t accessible by\nthe guest, and KVM won\u0027t read or write page data itself, but KVM will\ntrigger e.g. kvm_set_pfn_dirty() when zapping SPTEs, and thus completing\na zap of an invalid root _after_ the mmu_notifier returns is fatal.\n\n WARNING: CPU: 24 PID: 1496 at arch/x86/kvm/../../../virt/kvm/kvm_main.c:173 [kvm]\n RIP: 0010:kvm_is_zone_device_pfn+0x96/0xa0 [kvm]\n Call Trace:\n \u003cTASK\u003e\n kvm_set_pfn_dirty+0xa8/0xe0 [kvm]\n __handle_changed_spte+0x2ab/0x5e0 [kvm]\n __handle_changed_spte+0x2ab/0x5e0 [kvm]\n __handle_changed_spte+0x2ab/0x5e0 [kvm]\n zap_gfn_range+0x1f3/0x310 [kvm]\n kvm_tdp_mmu_zap_invalidated_roots+0x50/0x90 [kvm]\n kvm_mmu_zap_all_fast+0x177/0x1a0 [kvm]\n set_nx_huge_pages+0xb4/0x190 [kvm]\n param_attr_store+0x70/0x100\n module_attr_store+0x19/0x30\n kernfs_fop_write_iter+0x119/0x1b0\n new_sync_write+0x11c/0x1b0\n vfs_write+0x1cc/0x270\n ksys_write+0x5f/0xe0\n do_syscall_64+0x38/0xc0\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n \u003c/TASK\u003e",
"id": "GHSA-7fq4-85x5-74rc",
"modified": "2025-02-27T21:32:09Z",
"published": "2025-02-27T21:32:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47639"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0c8a8da182d4333d9bbb9131d765145568c847b2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8cf6f98ab1d16d5e607635a0c21c4231eb15367e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/af47248407c0c5ae52a752af1ab5ce5b0db91502"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d62007edf01f5c11f75d0f4b1e538fc52a5b1982"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
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.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
How durations are calculated
Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.
Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.
Loading timeline…
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.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.