CVE-2026-53359

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86: Fix shadow paging use-after-free due to unexpected role<br /> <br /> Commit 0cb2af2ea66ad ("KVM: x86: Fix shadow paging use-after-free due<br /> to unexpected GFN") fixed a shadow paging mismatch between stored and<br /> computed GFNs; the bug could be triggered by changing a PDE mapping from<br /> outside the guest, and then deleting a memslot. The rmap_remove()<br /> call would miss entries created after the PDE change because the GFN<br /> of the leaf SPTE does not match the GFN of the struct kvm_mmu_page.<br /> <br /> A similar hole however remains if the modified PDE points to a non-leaf<br /> page. In this case the gfn can be made to match, but the role does not<br /> match: the original large 2MB page creates a kvm_mmu_page with direct=1,<br /> while the new 4KB needs a kvm_mmu_page with direct=0. However,<br /> kvm_mmu_get_child_sp() does not compare the role, and therefore reuses<br /> the page.<br /> <br /> The next step is installing a leaf (4KB) SPTE on the new path which<br /> records an rmap entry under the gfn resolved by the walk. But when<br /> that child is zapped its parent kvm_mmu_page has direct=1 and<br /> kvm_mmu_page_get_gfn() computes the gfn for the 4KB page as<br /> sp-&gt;gfn + index instead of using sp-&gt;shadowed_translation[] (or sp-&gt;gfns[]<br /> in older kernels). It therefore fails to remove the recorded entry.<br /> <br /> When the memslot is dropped the shadow page is freed but the rmap<br /> entry survives, as in the scenario that was already fixed. Code that<br /> later walks that gfn (dirty logging, MMU notifier invalidation, and<br /> so on) dereferences an sptep that lies in the freed page, causing the<br /> use-after-free.