{"id":12895,"date":"2026-09-04T18:59:43","date_gmt":"2026-09-04T10:59:43","guid":{"rendered":"https:\/\/www.54iter.cn\/?vuln=cve-2026-53359"},"modified":"2026-09-04T18:59:43","modified_gmt":"2026-09-04T10:59:43","slug":"cve-2026-53359","status":"publish","type":"vuln","link":"https:\/\/www.54iter.cn\/?vuln=cve-2026-53359","title":{"rendered":"CVE-2026-53359 [HIGH] &#8211; In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: Fix shadow"},"content":{"rendered":"<p>In the Linux kernel, the following vulnerability has been resolved:<\/p>\n<p>KVM: x86: Fix shadow paging use-after-free due to unexpected role<\/p>\n<p>Commit 0cb2af2ea66ad (&#8220;KVM: x86: Fix shadow paging use-after-free due<br \/>\nto unexpected GFN&#8221;) fixed a shadow paging mismatch between stored and<br \/>\ncomputed GFNs; the bug could be triggered by changing a PDE mapping from<br \/>\noutside the guest, and then deleting a memslot.  The rmap_remove()<br \/>\ncall would miss entries created after the PDE change because the GFN<br \/>\nof the leaf SPTE does not match the GFN of the struct kvm_mmu_page.<\/p>\n<p>A similar hole however remains if the modified PDE points to a non-leaf<br \/>\npage.  In this case the gfn can be made to match, but the role does not<br \/>\nmatch: the original large 2MB page creates a kvm_mmu_page with direct=1,<br \/>\nwhile the new 4KB needs a kvm_mmu_page with direct=0.  However,<br \/>\nkvm_mmu_get_child_sp() does not compare the role, and therefore reuses<br \/>\nthe page.<\/p>\n<p>The next step is installing a leaf (4KB) SPTE on the new path which<br \/>\nrecords an rmap entry under the gfn resolved by the walk.  But when<br \/>\nthat child is zapped its parent kvm_mmu_page has direct=1 and<br \/>\nkvm_mmu_page_get_gfn() computes the gfn for the 4KB page as<br \/>\nsp-&gt;gfn + index instead of using sp-&gt;shadowed_translation[] (or sp-&gt;gfns[]<br \/>\nin older kernels).  It therefore fails to remove the recorded entry.<\/p>\n<p>When the memslot is dropped the shadow page is freed but the rmap<br \/>\nentry survives, as in the scenario that was already fixed.  Code that<br \/>\nlater walks that gfn (dirty logging, MMU notifier invalidation, and<br \/>\nso on) dereferences an sptep that lies in the freed page, causing the<br \/>\nuse-after-free.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>In the Linux kernel, the following vulnerability has been resolved:<\/p>\n<p>KVM: x86: Fix shadow paging use-after-free due to unexpected role<\/p>\n<p>Commit 0cb2af2ea66ad (&#8220;KVM: x86: Fix shadow paging use-after-fre<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-12895","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/12895","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=12895"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=12895"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=12895"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}