FKIE_CVE-2026-90040
Vulnerability from fkie_nvd - Published: 2026-09-16 11:17 - Updated: 2026-09-16 11:17
Severity
Summary
In the Linux kernel, the following vulnerability has been resolved:
KVM: SEV: Forcefully invalidate SNP VMSA if its backing gmem page is zapped
Wire up a gmem_invalidate_range() call for SNP VMs, and use it to force
vCPUs to reload/recheck their guest-provided VMSA if the backing gmem
page is being invalidated, e.g. is being PUNCH_HOLE'd. Use the same core
logic to handle invalidations as VMX does for the APIC-access page, as the
two concepts are nearly identical: shove the physical address of a page
into the vCPU's control structure:
1. Snapshot the invalidation sequence counter
2. Grab the pfn (from guest_memfd in this case)
3. Acquire mmu_lock for read
4. Re-request reload if retry is needed, otherwise commit the change.
Note, the re-request action in #4 is necessary as KVM's retry logic is
fuzzy, i.e. can get false positives. If the guest_memfd page has been
dropped, at some point a subsequent reload will fail to get a PFN from
guest_memfd, and KVM will fail KVM_RUN. If the retry was due to a false
positive, KVM will retry until there are no relevant MMU notifier events
(and will retry in the "outer" loop, i.e. will drop locks and resched as
needed).
Note #2! Take care to invalidate the VMSA when a relevant memslot is
DELETED or MOVED, as invalidations in response to PUNCH_HOLE are predicated
on memslot bindings (KVM doesn't know what GFN range(s) to invalidate
without a binding). And more importantly, the VMSA mapping requires a
memslot, i.e. must be invalidated if its memslots disappears, regardless of
the state of the underlying guest_memfd inode.
Failure to invalidate the vCPU's control.vmsa_pa (which is checked by
pre_sev_run()) can prevent KVM from properly freeing the page as firmware
will reject the RMPUPDATE to reclaim the page with FAIL_INUSE if the vCPU
is actively running, i.e. if VMSA page is in-use. That in turn leads to an
RMP #PF on the next use, as the page will still be assigned to the SNP VM.
SEV-SNP: RMPUPDATE failed for PFN 78d198, pg_level: 1, ret: 3
SEV-SNP: PFN 0x78d198, RMP entry: [0xfff0000000144001 - 0x000000000000000f]
CPU: 3 UID: 0 PID: 31345 Comm: sev_snp_vmsa_pu Tainted: G U O
Tainted: [U]=USER, [O]=OOT_MODULE
Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.86.0-102 01/25/2026
Call Trace:
<TASK>
dump_stack_lvl+0x54/0x70
rmpupdate+0x12c/0x140
rmp_make_shared+0x3b/0x60
sev_gmem_invalidate+0xe0/0x170 [kvm_amd]
delete_from_page_cache_batch+0x1d8/0x220
truncate_inode_pages_range+0x120/0x3d0
kvm_gmem_fallocate+0x19a/0x270 [kvm]
vfs_fallocate+0x1bc/0x1f0
__x64_sys_fallocate+0x48/0x70
do_syscall_64+0x10a/0x480
entry_SYSCALL_64_after_hwframe+0x4b/0x53
RIP: 0033:0x496c7e
</TASK>
------------[ cut here ]------------
SEV: Failed to update RMP entry for PFN 0x78d198 error -14
WARNING: arch/x86/kvm/svm/sev.c:5160 at sev_gmem_invalidate+0x126/0x170 [kvm_amd], CPU#3: sev_snp_vmsa_pu/31345
CPU: 3 UID: 0 PID: 31345 Comm: sev_snp_vmsa_pu Tainted: G U O
Tainted: [U]=USER, [O]=OOT_MODULE
Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.86.0-102 01/25/2026
RIP: 0010:sev_gmem_invalidate+0x12b/0x170 [kvm_amd]
Call Trace:
<TASK>
delete_from_page_cache_batch+0x1d8/0x220
truncate_inode_pages_range+0x120/0x3d0
kvm_gmem_fallocate+0x19a/0x270 [kvm]
vfs_fallocate+0x1bc/0x1f0
__x64_sys_fallocate+0x48/0x70
do_syscall_64+0x10a/0x480
entry_SYSCALL_64_after_hwframe+0x4b/0x53
RIP: 0033:0x496c7e
</TASK>
irq event stamp: 20689
hardirqs last enabled at (20699): [<ffffffff8e76092c>] __console_unlock+0x5c/0x60
hardirqs last disabled at (20708): [<ffffffff8e760911>] __console_unlock+0x41/0x60
softirqs last enabled at (20722): [<ffffffff8e6cd74e>] __irq_exit_rcu+0x7e/0x140
softirqs last disabled at (20717): [<ffffffff8e6cd74e>] __irq_exit_rcu+0x7e/0x140
---[ end trace 0000000000000000 ]---
BUG: unable to handle page fault for address: ffff99
---truncated---
References
Impacted products
| Vendor | Product | Version |
|---|
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"arch/x86/include/asm/kvm-x86-ops.h",
"arch/x86/include/asm/kvm_host.h",
"arch/x86/kvm/mmu/mmu.c",
"arch/x86/kvm/svm/sev.c",
"arch/x86/kvm/svm/svm.c",
"arch/x86/kvm/svm/svm.h",
"arch/x86/kvm/x86.c",
"include/linux/kvm_host.h",
"virt/kvm/guest_memfd.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "2640cc26ed0dd1bf6ec2f6852a60e494093db3e5",
"status": "affected",
"version": "e366f92ea99e1961fbad5e2110900e9f4fcb249b",
"versionType": "git"
},
{
"lessThan": "d1a3c216233413f57f5341a9b878b7e2dde7e785",
"status": "affected",
"version": "e366f92ea99e1961fbad5e2110900e9f4fcb249b",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"arch/x86/include/asm/kvm-x86-ops.h",
"arch/x86/include/asm/kvm_host.h",
"arch/x86/kvm/mmu/mmu.c",
"arch/x86/kvm/svm/sev.c",
"arch/x86/kvm/svm/svm.c",
"arch/x86/kvm/svm/svm.h",
"arch/x86/kvm/x86.c",
"include/linux/kvm_host.h",
"virt/kvm/guest_memfd.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "6.11"
},
{
"lessThan": "6.11",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "7.2.*",
"status": "unaffected",
"version": "7.2.5",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "7.3-rc1",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: SEV: Forcefully invalidate SNP VMSA if its backing gmem page is zapped\n\nWire up a gmem_invalidate_range() call for SNP VMs, and use it to force\nvCPUs to reload/recheck their guest-provided VMSA if the backing gmem\npage is being invalidated, e.g. is being PUNCH_HOLE\u0027d. Use the same core\nlogic to handle invalidations as VMX does for the APIC-access page, as the\ntwo concepts are nearly identical: shove the physical address of a page\ninto the vCPU\u0027s control structure:\n\n 1. Snapshot the invalidation sequence counter\n 2. Grab the pfn (from guest_memfd in this case)\n 3. Acquire mmu_lock for read\n 4. Re-request reload if retry is needed, otherwise commit the change.\n\nNote, the re-request action in #4 is necessary as KVM\u0027s retry logic is\nfuzzy, i.e. can get false positives. If the guest_memfd page has been\ndropped, at some point a subsequent reload will fail to get a PFN from\nguest_memfd, and KVM will fail KVM_RUN. If the retry was due to a false\npositive, KVM will retry until there are no relevant MMU notifier events\n(and will retry in the \"outer\" loop, i.e. will drop locks and resched as\nneeded).\n\nNote #2! Take care to invalidate the VMSA when a relevant memslot is\nDELETED or MOVED, as invalidations in response to PUNCH_HOLE are predicated\non memslot bindings (KVM doesn\u0027t know what GFN range(s) to invalidate\nwithout a binding). And more importantly, the VMSA mapping requires a\nmemslot, i.e. must be invalidated if its memslots disappears, regardless of\nthe state of the underlying guest_memfd inode.\n\nFailure to invalidate the vCPU\u0027s control.vmsa_pa (which is checked by\npre_sev_run()) can prevent KVM from properly freeing the page as firmware\nwill reject the RMPUPDATE to reclaim the page with FAIL_INUSE if the vCPU\nis actively running, i.e. if VMSA page is in-use. That in turn leads to an\nRMP #PF on the next use, as the page will still be assigned to the SNP VM.\n\n SEV-SNP: RMPUPDATE failed for PFN 78d198, pg_level: 1, ret: 3\n SEV-SNP: PFN 0x78d198, RMP entry: [0xfff0000000144001 - 0x000000000000000f]\n CPU: 3 UID: 0 PID: 31345 Comm: sev_snp_vmsa_pu Tainted: G U O\n Tainted: [U]=USER, [O]=OOT_MODULE\n Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.86.0-102 01/25/2026\n Call Trace:\n \u003cTASK\u003e\n dump_stack_lvl+0x54/0x70\n rmpupdate+0x12c/0x140\n rmp_make_shared+0x3b/0x60\n sev_gmem_invalidate+0xe0/0x170 [kvm_amd]\n delete_from_page_cache_batch+0x1d8/0x220\n truncate_inode_pages_range+0x120/0x3d0\n kvm_gmem_fallocate+0x19a/0x270 [kvm]\n vfs_fallocate+0x1bc/0x1f0\n __x64_sys_fallocate+0x48/0x70\n do_syscall_64+0x10a/0x480\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n RIP: 0033:0x496c7e\n \u003c/TASK\u003e\n ------------[ cut here ]------------\n SEV: Failed to update RMP entry for PFN 0x78d198 error -14\n WARNING: arch/x86/kvm/svm/sev.c:5160 at sev_gmem_invalidate+0x126/0x170 [kvm_amd], CPU#3: sev_snp_vmsa_pu/31345\n CPU: 3 UID: 0 PID: 31345 Comm: sev_snp_vmsa_pu Tainted: G U O\n Tainted: [U]=USER, [O]=OOT_MODULE\n Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.86.0-102 01/25/2026\n RIP: 0010:sev_gmem_invalidate+0x12b/0x170 [kvm_amd]\n Call Trace:\n \u003cTASK\u003e\n delete_from_page_cache_batch+0x1d8/0x220\n truncate_inode_pages_range+0x120/0x3d0\n kvm_gmem_fallocate+0x19a/0x270 [kvm]\n vfs_fallocate+0x1bc/0x1f0\n __x64_sys_fallocate+0x48/0x70\n do_syscall_64+0x10a/0x480\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n RIP: 0033:0x496c7e\n \u003c/TASK\u003e\n irq event stamp: 20689\n hardirqs last enabled at (20699): [\u003cffffffff8e76092c\u003e] __console_unlock+0x5c/0x60\n hardirqs last disabled at (20708): [\u003cffffffff8e760911\u003e] __console_unlock+0x41/0x60\n softirqs last enabled at (20722): [\u003cffffffff8e6cd74e\u003e] __irq_exit_rcu+0x7e/0x140\n softirqs last disabled at (20717): [\u003cffffffff8e6cd74e\u003e] __irq_exit_rcu+0x7e/0x140\n ---[ end trace 0000000000000000 ]---\n BUG: unable to handle page fault for address: ffff99\n---truncated---"
}
],
"id": "CVE-2026-90040",
"lastModified": "2026-09-16T11:17:17.213",
"metrics": {},
"published": "2026-09-16T11:17:17.213",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/2640cc26ed0dd1bf6ec2f6852a60e494093db3e5"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/d1a3c216233413f57f5341a9b878b7e2dde7e785"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Received"
}
Loading…
Loading…
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
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.
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
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.
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.
Loading…
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.
Loading…