In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
KVM: SEV: Forcefully invalidate SNP VMSA if its backing gmem page is zapped<\/p>\n
Wire 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:<\/p>\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.<\/p>\n
Note, 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).<\/p>\n
Note #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.<\/p>\n
Failure 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.<\/p>\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:<\/p>\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<\/p>\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:<\/p>\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<\/p>\n
irq event stamp: 20689
\n hardirqs last enabled at (20699): [] __console_unlock+0x5c\/0x60
\n hardirqs last disabled at (20708): [] __console_unlock+0x41\/0x60
\n softirqs last enabled at (20722): [] __irq_exit_rcu+0x7e\/0x140
\n softirqs last disabled at (20717): [] __irq_exit_rcu+0x7e\/0x140
\n —[ end trace 0000000000000000 ]—
\n BUG: unable to handle page fault for address: ffff99
\n—truncated—<\/p>\n","protected":false},"excerpt":{"rendered":"
In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
KVM: SEV: Forcefully invalidate SNP VMSA if its backing gmem page is zapped<\/p>\n
Wire up a gmem_invalidate_range() call for SNP VMs, an<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-24728","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/24728","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=24728"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=24728"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=24728"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}