<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://db.gcve.eu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-11-12T07:22:21.771350+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@gcve.eu</email>
  </author>
  <link href="https://db.gcve.eu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://db.gcve.eu/vuln/cve-2026-98467</id>
    <title>CVE-2026-98467 — KVM: arm64: nv: Fix null ptr deref on nested wp/unmap, teardown race</title>
    <updated>2026-11-12T07:22:21.772868+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Linux</p>
<p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>KVM: arm64: nv: Fix null ptr deref on nested wp/unmap, teardown race</p>
<p>Commit 7270cc9157f4 ("KVM: arm64: nv: Handle VNCR_EL2 invalidation from MMU
notifiers") introduced VNCR_EL2 invalidation in both kvm_nested_s2_unmap()
and kvm_nested_s2_wp().</p>
<p>However at the point of this being performed concurrent stage 2 teardown of
a nested guest can cause kvm-&gt;arch.mmu.pgt to be set to NULL.</p>
<p>This happens in kvm_flush_shadow_all() -&gt; kvm_arch_flush_shadow_all() -&gt;
kvm_free_stage2_pgd() and is performed under the kvm-&gt;mmu_lock.</p>
<p>Commit ec14c272408a ("KVM: arm64: nv: Unmap/flush shadow stage 2 page
tables") introduced the teardown of the entire nested MMU range, which then
invokes stage2_apply_range() with resched=true:</p>
<p>mmu_notifier_invalidate_range_start()
  -&gt; ... -&gt; kvm_mmu_notifier_invalidate_range_start()
    -&gt; kvm_mmu_unmap_gfn_range()
      -&gt; kvm_unmap_gfn_range()
        -&gt; kvm_nested_s2_unmap()
          -&gt; kvm_stage2_unmap_range()
            -&gt; __unmap_stage2_range()
                -&gt; stage2_apply_range()</p>
<p>This means that stage2_apply_range() can drop the kvm-&gt;mmu_lock and thus
concurrent progress can be made in lockstep with
kvm_arch_flush_shadow_all().</p>
<p>If kvm_arch_flush_shadow_all() advances ahead of stage2_apply_range() and
completes its operation it guarantees a NULL pointer deref.</p>
<p>Since kvm_free_stage2_pgd() is performed under the kvm-&gt;mmu_lock this will
either be observed NULL or not and serialise…</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/cve-2026-98467"/>
  </entry>
</feed>
