CVE-2026-46113 in Linux
Zusammenfassung
von VulDB • 29.05.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
KVM: x86: Behebung eines Use-After-Free-Fehlers beim Shadow Paging aufgrund einer unerwarteten GFN
Das Shadow-MMU berechnet GFNs für direkte Shadow-Seiten unter Verwendung von sp->gfn plus dem SPTE-Index. Diese Annahme gilt beim Shadow Paging nicht mehr, wenn die Gast-Seitentabellen zwischen VM-Einträgen geändert werden (ähnlich wie in Commit aad885e77496, „KVM: x86/mmu: Vorhandene präsente SPTE auch beim Erstellen einer MMIO-SPTE löschen/entfernen“, 2026-03-27). Der Ablauf ist wie folgt:
- Eine PDE wird für eine 2-MB-Zuordnung installiert, und eine Seite in diesem Bereich wird accessed. KVM erstellt ein kvm_mmu_page, das aus 512 4-KB-Seiten besteht; das kvm_mmu_page wird von FNAME(fetch) als direkt-zugewiesen markiert, da die Zuordnung des Gastsystems eine große Seite ist (und somit zusammenhängend).
- Die PDE-Zuordnung wird außerhalb des Gastsystems geändert.
- Der Gast greift auf eine andere Seite im selben 2-MB-Bereich zu. KVM installiert ein neues Leaf-SPTE und einen rmap-Eintrag; das SPTE verwendet die „korrekte“ GFN (d. h. basierend auf der neuen Zuordnung, wie im vorherigen Schritt geändert), aber diese GFN liegt außerhalb des Bereichs [sp->gfn, sp->gfn + 511]; daher kann der rmap-Eintrag nicht gefunden und entfernt werden, wenn das kvm_mmu_page gelöscht wird.
- Der Memslot, der die erste 2-MB-Zuordnung abdeckt, wird gelöscht, und das kvm_mmu_page für die nun ungültige GPA wird gelöscht. rmap_remove() betrachtet jedoch nur den in Schritt 1 festgelegten Bereich [sp->gfn, sp->gfn + 511] und findet den in Schritt 3 aufgezeichneten rmap-Eintrag nicht.
- Jeder Vorgang, der einen rmap-Durchlauf für dieselbe Seite verursacht, die in Schritt 3 zugegriffen wurde, durchläuft dann einen veralteten rmap und dereferenziert ein freigegebenes kvm_mmu_page. Dazu gehören Dirty-Logging oder MMU-Notifier-Invalidierungen (z. B. von MADV_DONTNEED).
Das zugrunde liegende Problem besteht darin, dass KVMs Durchlaufen von Shadow-PTEs davon ausgeht, dass, wenn ein SPTE vorhanden ist, wenn KVM ein nicht-Leaf-SPTE installieren möchte, das vorhandene kvm_mmu_page für die korrekte GFN sein muss. Da der einzige Weg, damit die GFN falsch ist, darin besteht, dass KVM einen Fehler gemacht und eine SPTE nicht gelöscht hat ... was nicht passieren sollte, aber *tatsächlich* nur als Reaktion auf einen Gast-Schreibvorgang geschieht.
Dieser Fehler existiert buchstäblich seit Ewigkeiten, da sogar die erste Version von KVM davon ausgeht, dass die GFN übereinstimmt, und in die „falsche“ Shadow-Seite läuft. Dies war jedoch nur eine Ungenauigkeit, bis 2032a93d66fa („KVM: MMU: gfns-Seite für direkte MMU-Seiten nicht zuweisen“) hinzukam.
Beheben Sie dies, indem Sie auf einen Ziel-GFN-Mismatch prüfen und das vorhandene SPTE löschen. Auf diese Weise sind die alten SP- und rmap-Einträge verschwunden, KVM installiert den rmap am richtigen Ort, und alle sind zufrieden.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.