{"id":"CVE-2026-90040","summary":"KVM: SEV: Forcefully invalidate SNP VMSA if its backing gmem page is zapped","details":"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   \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---","modified":"2026-09-18T03:48:34.909708441Z","published":"2026-09-16T10:33:38.790Z","database_specific":{"osv_generated_from":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/90xxx/CVE-2026-90040.json","cna_assigner":"Linux"},"references":[{"type":"WEB","url":"https://git.kernel.org/stable/c/2640cc26ed0dd1bf6ec2f6852a60e494093db3e5"},{"type":"WEB","url":"https://git.kernel.org/stable/c/d1a3c216233413f57f5341a9b878b7e2dde7e785"},{"type":"ADVISORY","url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/90xxx/CVE-2026-90040.json"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-90040"},{"type":"PACKAGE","url":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"}],"affected":[{"ranges":[{"type":"GIT","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","events":[{"introduced":"e366f92ea99e1961fbad5e2110900e9f4fcb249b"},{"fixed":"2640cc26ed0dd1bf6ec2f6852a60e494093db3e5"},{"fixed":"d1a3c216233413f57f5341a9b878b7e2dde7e785"}]}],"database_specific":{"source":"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-90040.json"}},{"package":{"name":"Kernel","ecosystem":"Linux"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"6.11.0"},{"fixed":"7.2.5"}]}],"database_specific":{"source":"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-90040.json"}}],"schema_version":"1.9.0"}