<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://db.gcve.eu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Thu, 12 Nov 2026 06:55:57 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-98467 — KVM: arm64: nv: Fix null ptr deref on nested wp/unmap, teardown race</title>
      <link>https://db.gcve.eu/vuln/cve-2026-98467</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;KVM: arm64: nv: Fix null ptr deref on nested wp/unmap, teardown race&lt;/p&gt;
&lt;p&gt;Commit 7270cc9157f4 (&amp;#34;KVM: arm64: nv: Handle VNCR_EL2 invalidation from MMU
notifiers&amp;#34;) introduced VNCR_EL2 invalidation in both kvm_nested_s2_unmap()
and kvm_nested_s2_wp().&lt;/p&gt;
&lt;p&gt;However at the point of this being performed concurrent stage 2 teardown of
a nested guest can cause kvm-&amp;gt;arch.mmu.pgt to be set to NULL.&lt;/p&gt;
&lt;p&gt;This happens in kvm_flush_shadow_all() -&amp;gt; kvm_arch_flush_shadow_all() -&amp;gt;
kvm_free_stage2_pgd() and is performed under the kvm-&amp;gt;mmu_lock.&lt;/p&gt;
&lt;p&gt;Commit ec14c272408a (&amp;#34;KVM: arm64: nv: Unmap/flush shadow stage 2 page
tables&amp;#34;) introduced the teardown of the entire nested MMU range, which then
invokes stage2_apply_range() with resched=true:&lt;/p&gt;
&lt;p&gt;mmu_notifier_invalidate_range_start()
  -&amp;gt; ... -&amp;gt; kvm_mmu_notifier_invalidate_range_start()
    -&amp;gt; kvm_mmu_unmap_gfn_range()
      -&amp;gt; kvm_unmap_gfn_range()
        -&amp;gt; kvm_nested_s2_unmap()
          -&amp;gt; kvm_stage2_unmap_range()
            -&amp;gt; __unmap_stage2_range()
                -&amp;gt; stage2_apply_range()&lt;/p&gt;
&lt;p&gt;This means that stage2_apply_range() can drop the kvm-&amp;gt;mmu_lock and thus
concurrent progress can be made in lockstep with
kvm_arch_flush_shadow_all().&lt;/p&gt;
&lt;p&gt;If kvm_arch_flush_shadow_all() advances ahead of stage2_apply_range() and
completes its operation it guarantees a NULL pointer deref.&lt;/p&gt;
&lt;p&gt;Since kvm_free_stage2_pgd() is performed under the kvm-&amp;gt;mmu_lock this will
either be observed NULL or not and serialise…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;KVM: arm64: nv: Fix null ptr deref on nested wp/unmap, teardown race&lt;/p&gt;
&lt;p&gt;Commit 7270cc9157f4 (&amp;#34;KVM: arm64: nv: Handle VNCR_EL2 invalidation from MMU
notifiers&amp;#34;) introduced VNCR_EL2 invalidation in both kvm_nested_s2_unmap()
and kvm_nested_s2_wp().&lt;/p&gt;
&lt;p&gt;However at the point of this being performed concurrent stage 2 teardown of
a nested guest can cause kvm-&amp;gt;arch.mmu.pgt to be set to NULL.&lt;/p&gt;
&lt;p&gt;This happens in kvm_flush_shadow_all() -&amp;gt; kvm_arch_flush_shadow_all() -&amp;gt;
kvm_free_stage2_pgd() and is performed under the kvm-&amp;gt;mmu_lock.&lt;/p&gt;
&lt;p&gt;Commit ec14c272408a (&amp;#34;KVM: arm64: nv: Unmap/flush shadow stage 2 page
tables&amp;#34;) introduced the teardown of the entire nested MMU range, which then
invokes stage2_apply_range() with resched=true:&lt;/p&gt;
&lt;p&gt;mmu_notifier_invalidate_range_start()
  -&amp;gt; ... -&amp;gt; kvm_mmu_notifier_invalidate_range_start()
    -&amp;gt; kvm_mmu_unmap_gfn_range()
      -&amp;gt; kvm_unmap_gfn_range()
        -&amp;gt; kvm_nested_s2_unmap()
          -&amp;gt; kvm_stage2_unmap_range()
            -&amp;gt; __unmap_stage2_range()
                -&amp;gt; stage2_apply_range()&lt;/p&gt;
&lt;p&gt;This means that stage2_apply_range() can drop the kvm-&amp;gt;mmu_lock and thus
concurrent progress can be made in lockstep with
kvm_arch_flush_shadow_all().&lt;/p&gt;
&lt;p&gt;If kvm_arch_flush_shadow_all() advances ahead of stage2_apply_range() and
completes its operation it guarantees a NULL pointer deref.&lt;/p&gt;
&lt;p&gt;Since kvm_free_stage2_pgd() is performed under the kvm-&amp;gt;mmu_lock this will
either be observed NULL or not and serialise…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/cve-2026-98467</guid>
    </item>
  </channel>
</rss>
