CVE-2026-53359
Beschrijving NL
In de Linux kernel is de volgende kwetsbaarheid verholpen:
KVM: x86: Fix shadow paging use-after-free vanwege onverwachte rol
Commit 0cb2af2ea66ad ("KVM: x86: Fix shadow paging use-after-free due
naar onverwachte GFN") een schaduw paging mismatch tussen opgeslagen en
berekende GFN's; de bug kan worden geactiveerd door een PDE-toewijzing te wijzigen van
buiten de gast en vervolgens een memslot verwijderen. De rmap_remove()
oproep zou posten missen die zijn gemaakt na de PDE-wijziging omdat de GFN
van de leaf SPTE komt niet overeen met de GFN van de struct kvm_mmu_page. Er blijft echter een soortgelijk gat over als de gewijzigde PDE naar een niet-blad wijst
pagina. In dit geval kan de gfn worden aangepast, maar de rol is niet
match: de originele grote 2MB pagina maakt een kvm_mmu_page met direct=1,
terwijl de nieuwe 4KB een kvm_mmu_page nodig heeft met direct=0. Kvm_mmu_get_child_sp() vergelijkt de rol echter niet en gebruikt deze daarom opnieuw
de pagina. De volgende stap is het installeren van een Leaf (4KB) SPTE op het nieuwe pad dat
registreert een rmap-ingang onder de gfn opgelost door de wandeling. Maar wanneer
dat kind wordt gezapt, heeft zijn ouder kvm_mmu_page direct=1 en
kvm_mmu_page_get_gfn() berekent de gfn voor de 4KB-pagina als
sp->gfn + index in plaats van sp->shadowed_translation[] (of sp->gfns[]
in oudere kernels). Hij slaagt er dus niet in om de opgenomen invoer te verwijderen. Wanneer de memslot wordt verwijderd, wordt de schaduwpagina vrijgegeven, maar de rmap
invoer overleeft, zoals in het scenario dat al was vastgesteld. Code die
later loopt die gfn (dirty logging, MMU notifier invalidation, en
enzovoort) verwijst naar een sptep die in de bevrijde pagina ligt, waardoor de
use-after-free.
Origineel (Engels) tonen
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Fix shadow paging use-after-free due to unexpected role
Commit 0cb2af2ea66ad ("KVM: x86: Fix shadow paging use-after-free due
to unexpected GFN") fixed a shadow paging mismatch between stored and
computed GFNs; the bug could be triggered by changing a PDE mapping from
outside the guest, and then deleting a memslot. The rmap_remove()
call would miss entries created after the PDE change because the GFN
of the leaf SPTE does not match the GFN of the struct kvm_mmu_page.
A similar hole however remains if the modified PDE points to a non-leaf
page. In this case the gfn can be made to match, but the role does not
match: the original large 2MB page creates a kvm_mmu_page with direct=1,
while the new 4KB needs a kvm_mmu_page with direct=0. However,
kvm_mmu_get_child_sp() does not compare the role, and therefore reuses
the page.
The next step is installing a leaf (4KB) SPTE on the new path which
records an rmap entry under the gfn resolved by the walk. But when
that child is zapped its parent kvm_mmu_page has direct=1 and
kvm_mmu_page_get_gfn() computes the gfn for the 4KB page as
sp->gfn + index instead of using sp->shadowed_translation[] (or sp->gfns[]
in older kernels). It therefore fails to remove the recorded entry.
When the memslot is dropped the shadow page is freed but the rmap
entry survives, as in the scenario that was already fixed. Code that
later walks that gfn (dirty logging, MMU notifier invalidation, and
so on) dereferences an sptep that lies in the freed page, causing the
use-after-free.