CVE-2026-90040: KVM: SEV: Forcefully invalidate SNP VMSA if its backing gmem page is zapped

Published Sep 16, 2026
·
Updated

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 gmeminvalidaterange() 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 PUNCHHOLE'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 guestmemfd in this case) 3. Acquire mmulock 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 guestmemfd page has been dropped, at some point a subsequent reload will fail to get a PFN from guestmemfd, and KVM will fail KVMRUN. 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 PUNCHHOLE 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 guestmemfd inode.

Failure to invalidate the vCPU's control.vmsapa (which is checked by presevrun()) can prevent KVM from properly freeing the page as firmware will reject the RMPUPDATE to reclaim the page with FAILINUSE 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, pglevel: 1, ret: 3 SEV-SNP: PFN 0x78d198, RMP entry: [0xfff0000000144001 - 0x000000000000000f] CPU: 3 UID: 0 PID: 31345 Comm: sevsnpvmsapu Tainted: G U O Tainted: [U]=USER, [O]=OOTMODULE Hardware name: Google, Inc. ArcadiaIT80/ArcadiaIT80, BIOS 34.86.0-102 01/25/2026 Call Trace: <TASK> dumpstacklvl+0x54/0x70 rmpupdate+0x12c/0x140 rmpmakeshared+0x3b/0x60 sevgmeminvalidate+0xe0/0x170 [kvmamd] deletefrompagecachebatch+0x1d8/0x220 truncateinodepagesrange+0x120/0x3d0 kvmgmemfallocate+0x19a/0x270 [kvm] vfsfallocate+0x1bc/0x1f0 x64sysfallocate+0x48/0x70 dosyscall64+0x10a/0x480 entrySYSCALL64afterhwframe+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 sevgmeminvalidate+0x126/0x170 [kvmamd], CPU#3: sevsnpvmsapu/31345 CPU: 3 UID: 0 PID: 31345 Comm: sevsnpvmsapu Tainted: G U O Tainted: [U]=USER, [O]=OOTMODULE Hardware name: Google, Inc. ArcadiaIT80/ArcadiaIT80, BIOS 34.86.0-102 01/25/2026 RIP: 0010:sevgmeminvalidate+0x12b/0x170 [kvmamd] Call Trace: <TASK> deletefrompagecachebatch+0x1d8/0x220 truncateinodepagesrange+0x120/0x3d0 kvmgmemfallocate+0x19a/0x270 [kvm] vfsfallocate+0x1bc/0x1f0 x64sysfallocate+0x48/0x70 dosyscall64+0x10a/0x480 entrySYSCALL64afterhwframe+0x4b/0x53 RIP: 0033:0x496c7e </TASK> irq event stamp: 20689 hardirqs last enabled at (20699): [<ffffffff8e76092c>] consoleunlock+0x5c/0x60 hardirqs last disabled at (20708): [<ffffffff8e760911>] consoleunlock+0x41/0x60 softirqs last enabled at (20722): [<ffffffff8e6cd74e>] irqexitrcu+0x7e/0x140 softirqs last disabled at (20717): [<ffffffff8e6cd74e>] irqexitrcu+0x7e/0x140 ---[ end trace 0000000000000000 ]--- BUG: unable to handle page fault for address: ffff99 ---truncated---

Affected Software

1 affected component
Linux Kernel

Event History

Sep 16, 2026
CVE Published
via MITRE·10:33 AM
Data Sourced
via MITRE·10:33 AM
Description

Frequently Asked Questions

1

Which systems are exposed to this issue?

The issue concerns Linux Kernel KVM SEV-SNP virtual machines that use a guest-provided VMSA backed by guest_memfd/gmem. The described trigger is invalidation of that backing page, such as a PUNCH_HOLE operation.

2

What condition is required to trigger the flaw?

The backing gmem page for an SNP VMSA must be invalidated or dropped while KVM is handling the vCPU state. The fix ensures vCPUs reload and recheck the guest-provided VMSA after such invalidation.

3

How can an administrator recognize the affected failure condition?

After the backing guest_memfd page has been dropped, a subsequent VMSA reload can fail to obtain a PFN from guest_memfd, causing KVM_RUN to fail. This behavior is described as the eventual outcome when the page is no longer available.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203