Odebrany

CVE-2026-90040

opublikowano: 16.09.2026, 13:17

modyfikacja: 16.09.2026, 13:17

Ocena CVSS

n/a

Brak oceny

Oficjalne źródła

>_ Opis

Tłumaczenie automatyczne – może zawierać nieścisłości.

W jądrze Linuksa usunięto następującą lukę:

KVM: SEV: Wymuś unieważnienie SNP VMSA, jeśli jego zapasowa strona gmem jest spakowana

Połącz wywołanie gmem_invalidate_range() dla maszyn wirtualnych SNP i użyj go do wymuszenia
vCPU, aby ponownie załadować/ponownie sprawdzić udostępnioną przez gościa maszynę VMSA, jeśli zapasowy gmem
strona jest unieważniana, np. jest wykonywany PUNCH_HOLE. Użyj tego samego rdzenia
logika do obsługi unieważnień, tak jak robi to VMX dla strony dostępu APIC, ponieważ
dwie koncepcje są prawie identyczne: przesuń fizyczny adres strony
do struktury kontrolnej vCPU:

1. Zrób migawkę licznika sekwencji unieważnień
2. Chwyć pfn (w tym przypadku z Guest_memfd)
3. Uzyskaj mmu_lock do odczytu
4. Poproś o ponowne załadowanie, jeśli konieczna jest ponowna próba, w przeciwnym razie zatwierdź zmianę.

Uwaga: czynność ponownego żądania opisana w punkcie 4 jest konieczna ze względu na logikę ponawiania KVM
rozmyte, tj. mogą uzyskać fałszywie dodatnie wyniki. Jeśli strona Guest_memfd została
upuszczony, w pewnym momencie przy kolejnym przeładowaniu nie uda się uzyskać PFN
Guest_memfd, a KVM zakończy się niepowodzeniem KVM_RUN. Jeśli ponowna próba była spowodowana błędem
pozytywny, KVM będzie ponawiał próbę, dopóki nie będzie żadnych odpowiednich zdarzeń powiadamiających MMU
(i spróbuje ponownie w „zewnętrznej” pętli, tj. porzuci blokady i ponownie przełączy się na
potrzebne).

Uwaga nr 2! Uważaj, aby unieważnić VMSA, gdy znajduje się odpowiedni slot memslot
DELETED lub MOVED, ponieważ przewidywane są unieważnienia w odpowiedzi na PUNCH_HOLE
na powiązaniach memslot (KVM nie wie, jakie zakresy GFN należy unieważnić
bez wiązania). Co ważniejsze, mapowanie VMSA wymaga:
memslot, tj. musi zostać unieważniony, jeśli jego memslot zniknie, niezależnie od tego
stan bazowego i-węzła gościa_memfd.

Nieunieważnienie pliku control.vmsa_pa vCPU (który jest sprawdzany przez
pre_sev_run()) może uniemożliwić KVM prawidłowe zwolnienie strony jako oprogramowania sprzętowego
odrzuci RMUPPDATE, aby odzyskać stronę z FAIL_INUSE, jeśli vCPU
jest aktywnie uruchomiony, tj. jeśli strona VMSA jest w użyciu. To z kolei prowadzi do
RMP #PF przy następnym użyciu, ponieważ strona będzie nadal przypisana do maszyny SNP VM.

SEV-SNP: RMUPPDATE nie powiodło się dla PFN 78d198, pg_level: 1, ret: 3
SEV-SNP: PFN 0x78d198, wpis RMP: [0xfff0000000144001 - 0x000000000000000f]
Procesor: 3 UID: 0 PID: 31345 Comm: sev_snp_vmsa_pu Tainted: G U O
Skażony: [U]=USER, [O]=OOT_MODULE
Nazwa sprzętu: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.86.0-102 25.01.2026
Zadzwoń do śledzenia:
<ZADANIE>
dump_stack_lvl+0x54/0x70
rmpupdate+0x12c/0x140
rmp_make_shared+0x3b/0x60
sev_gmem_invalidate+0xe0/0x170 [kvm_amd]
usuń_z_strony_cache_batch+0x1d8/0x220
truncate_inode_pages_range+0x120/0x3d0
kvm_gmem_fallocate+0x19a/0x270 [kvm]
vfs_fallocate+0x1bc/0x1f0
__x64_sys_fallocate+0x48/0x70
do_syscall_64+0x10a/0x480
wpis_SYSCALL_64_after_hwframe+0x4b/0x53
RIP: 0033:0x496c7e
</ZADANIE>
------------[przetnij tutaj ]------------
SEV: Nie udało się zaktualizować wpisu RMP dla błędu PFN 0x78d198 -14
OSTRZEŻENIE: arch/x86/kvm/svm/sev.c:5160 w sev_gmem_invalidate+0x126/0x170 [kvm_amd], CPU#3: sev_snp_vmsa_pu/31345
Procesor: 3 UID: 0 PID: 31345 Comm: sev_snp_vmsa_pu Tainted: G U O
Skażony: [U]=USER, [O]=OOT_MODULE
Nazwa sprzętu: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.86.0-102 25.01.2026
RIP: 0010:sev_gmem_invalidate+0x12b/0x170 [kvm_amd]
Zadzwoń do śledzenia:
<ZADANIE>
usuń_z_strony_cache_batch+0x1d8/0x220
truncate_inode_pages_range+0x120/0x3d0
kvm_gmem_fallocate+0x19a/0x270 [kvm]
vfs_fallocate+0x1bc/0x1f0
__x64_sys_fallocate+0x48/0x70
do_syscall_64+0x10a/0x480
wpis_SYSCALL_64_after_hwframe+0x4b/0x53
RIP: 0033:0x496c7e
</ZADANIE>
Znaczek zdarzenia irq: 20689
hardirqs ostatnio włączony o (20699): [<ffffffff8e76092c>] __console_unlock+0x5c/0x60
Hardirqs ostatnio wyłączony o (20708): [<ffffffff8e760911>] __console_unlock+0x41/0x60
softirqs ostatnio włączony o (20722): [<ffffffff8e6cd74e>] __irq_exit_rcu+0x7e/0x140
softirqs ostatnio wyłączony o (20717): [<ffffffff8e6cd74e>] __irq_exit_rcu+0x7e/0x140
---[koniec śladu 0000000000000000 ]---
BŁĄD: nie można obsłużyć błędu strony dla adresu: ffff99
---obcięty---

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'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 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's 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 "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 PUNCH_HOLE 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 guest_memfd inode.

Failure to invalidate the vCPU's 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:
<TASK>
dump_stack_lvl+0x54/0x70
rmpupdate+0x12c/0x140
rmp_make_shared+0x3b/0x60
sev_gmem_invalidate+0xe0/0x170 [kvm_amd]
delete_from_page_cache_batch+0x1d8/0x220
truncate_inode_pages_range+0x120/0x3d0
kvm_gmem_fallocate+0x19a/0x270 [kvm]
vfs_fallocate+0x1bc/0x1f0
__x64_sys_fallocate+0x48/0x70
do_syscall_64+0x10a/0x480
entry_SYSCALL_64_after_hwframe+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 sev_gmem_invalidate+0x126/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+0x12b/0x170 [kvm_amd]
Call Trace:
<TASK>
delete_from_page_cache_batch+0x1d8/0x220
truncate_inode_pages_range+0x120/0x3d0
kvm_gmem_fallocate+0x19a/0x270 [kvm]
vfs_fallocate+0x1bc/0x1f0
__x64_sys_fallocate+0x48/0x70
do_syscall_64+0x10a/0x480
entry_SYSCALL_64_after_hwframe+0x4b/0x53
RIP: 0033:0x496c7e
</TASK>
irq event stamp: 20689
hardirqs last enabled at (20699): [<ffffffff8e76092c>] __console_unlock+0x5c/0x60
hardirqs last disabled at (20708): [<ffffffff8e760911>] __console_unlock+0x41/0x60
softirqs last enabled at (20722): [<ffffffff8e6cd74e>] __irq_exit_rcu+0x7e/0x140
softirqs last disabled at (20717): [<ffffffff8e6cd74e>] __irq_exit_rcu+0x7e/0x140
---[ end trace 0000000000000000 ]---
BUG: unable to handle page fault for address: ffff99
---truncated---

>_ Referencje

Dane podatności pochodzą z oficjalnych źródeł (CVE® List / NVD). Opisy po polsku są tłumaczone automatycznie i mogą zawierać nieścisłości – na stronie rekordu można wyświetlić wersję angielską.

This product uses the NVD API but is not endorsed or certified by the NVD.

CVE Usage: MITRE hereby grants you a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Common Vulnerabilities and Exposures (CVE®). Any copy you make for such purposes is authorized provided that you reproduce MITRE's copyright designation and this license in any such copy. ALL DOCUMENTS AND THE INFORMATION CONTAINED THEREIN PROVIDED BY MITRE ARE PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND.

NVD Terms of Use / CVE® Terms of Use / nvd.nist.gov / cve.org

<< baza_cve