{"cve":"CVE-2026-90040","nvd":{"published":"2026-09-16T11:17:17.213","modified":"2026-10-19T09:18:52.240","status":"Received","description":"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'd.  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's 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's 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't 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's 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   <TASK>\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   </TASK>\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   <TASK>\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   </TASK>\n  irq event stamp: 20689\n  hardirqs last  enabled at (20699): [<ffffffff8e76092c>] __console_unlock+0x5c/0x60\n  hardirqs last disabled at (20708): [<ffffffff8e760911>] __console_unlock+0x41/0x60\n  softirqs last  enabled at (20722): [<ffffffff8e6cd74e>] __irq_exit_rcu+0x7e/0x140\n  softirqs last disabled at (20717): [<ffffffff8e6cd74e>] __irq_exit_rcu+0x7e/0x140\n  ---[ end trace 0000000000000000 ]---\n  BUG: unable to handle page fault for address: ffff99\n---truncated---","cvss_v4":null,"cvss_v3":null,"cwes":[],"references":["https://git.kernel.org/stable/c/2640cc26ed0dd1bf6ec2f6852a60e494093db3e5","https://git.kernel.org/stable/c/d1a3c216233413f57f5341a9b878b7e2dde7e785","https://git.kernel.org/stable/c/ef4dee4640c6adc3051401399b0788135e77d50b"],"products":[],"source":"nvd","synced_at":"2026-10-19T22:54:41.405518556+00:00"},"epss":{"cve":"CVE-2026-90040","score":0.00206,"percentile":0.10595,"date":"2026-10-25"},"kev":null,"osv":[],"attribution":["This product uses the NVD API but is not endorsed or certified by the NVD.","EPSS scores: FIRST Exploit Prediction Scoring System, https://www.first.org/epss","Known exploited vulnerabilities: CISA Known Exploited Vulnerabilities Catalog, https://www.cisa.gov/known-exploited-vulnerabilities-catalog","Package advisories: OSV (https://osv.dev), from the GitHub Advisory Database, PyPA, Go, RustSec and other ecosystem databases, under CC-BY 4.0 or CC0","CVE records: the CVE Program's CVE List (https://www.cve.org), under its terms of use (https://www.cve.org/Legal/TermsOfUse). CVE is a registered trademark of The MITRE Corporation; this product is not affiliated with the CVE Program."]}