{
  "cveId": "CVE-2026-90040",
  "url": "https://patchblox.com/security/cve/CVE-2026-90040",
  "summary": "CVE-2026-90040 is fixed in linux on 1 platform by DEBIAN-CVE-2026-90040 (version 7.2.6-1), released September 23, 2026. It is not reported as exploited. Patch Radar priority: Routine.",
  "title": "KVM: SEV: Forcefully invalidate SNP VMSA if its backing gmem page is zapped",
  "description": "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\u0027d.  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\u0027s 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\u0027s 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 \u0022outer\u0022 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\u0027t 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\u0027s 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:    \u003CTASK\u003E    dump_stack_lvl\u002B0x54/0x70    rmpupdate\u002B0x12c/0x140    rmp_make_shared\u002B0x3b/0x60    sev_gmem_invalidate\u002B0xe0/0x170 [kvm_amd]    delete_from_page_cache_batch\u002B0x1d8/0x220    truncate_inode_pages_range\u002B0x120/0x3d0    kvm_gmem_fallocate\u002B0x19a/0x270 [kvm]    vfs_fallocate\u002B0x1bc/0x1f0    __x64_sys_fallocate\u002B0x48/0x70    do_syscall_64\u002B0x10a/0x480    entry_SYSCALL_64_after_hwframe\u002B0x4b/0x53   RIP: 0033:0x496c7e    \u003C/TASK\u003E   ------------[ 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\u002B0x126/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\u002B0x12b/0x170 [kvm_amd]   Call Trace:    \u003CTASK\u003E    delete_from_page_cache_batch\u002B0x1d8/0x220    truncate_inode_pages_range\u002B0x120/0x3d0    kvm_gmem_fallocate\u002B0x19a/0x270 [kvm]    vfs_fallocate\u002B0x1bc/0x1f0    __x64_sys_fallocate\u002B0x48/0x70    do_syscall_64\u002B0x10a/0x480    entry_SYSCALL_64_after_hwframe\u002B0x4b/0x53   RIP: 0033:0x496c7e    \u003C/TASK\u003E   irq event stamp: 20689   hardirqs last  enabled at (20699): [\u003Cffffffff8e76092c\u003E] __console_unlock\u002B0x5c/0x60   hardirqs last disabled at (20708): [\u003Cffffffff8e760911\u003E] __console_unlock\u002B0x41/0x60   softirqs last  enabled at (20722): [\u003Cffffffff8e6cd74e\u003E] __irq_exit_rcu\u002B0x7e/0x140   softirqs last disabled at (20717): [\u003Cffffffff8e6cd74e\u003E] __irq_exit_rcu\u002B0x7e/0x140   ---[ end trace 0000000000000000 ]---   BUG: unable to handle page fault for address: ffff99 ---truncated---",
  "published": "2026-09-16T11:17:17Z",
  "severity": "",
  "epss": 0.00206,
  "epssPercentile": 0.10776,
  "priority": "Routine",
  "priorityTier": 4,
  "exploited": false,
  "vendorExploited": false,
  "disclosed": false,
  "vendorAdvisory": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-90040",
  "fixes": [
    {
      "platform": "linux",
      "product": "linux",
      "release": "Debian 14",
      "fixedVersion": "7.2.6-1",
      "fix": "DEBIAN-CVE-2026-90040",
      "url": "https://patchblox.com/security/fix/linux/debian-cve-2026-90040",
      "released": "2026-09-23T19:19:02Z"
    }
  ],
  "noFixYet": [],
  "dataAsOf": "2026-11-08T13:06:02Z",
  "attribution": {
    "text": "Data: Patchblox Patch Radar",
    "url": "https://patchblox.com/security/patch-radar",
    "terms": "https://patchblox.com/security/patch-radar/use-the-data"
  }
}