<?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://vulnerability.circl.lu</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>Tue, 29 Sep 2026 04:43:51 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-74672 — mm/vmalloc: acquire init_mm lock on huge vmap to avoid ptdump UAF</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-74672</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;mm/vmalloc: acquire init_mm lock on huge vmap to avoid ptdump UAF&lt;/p&gt;
&lt;p&gt;Patch series &amp;#34;mm: fix UAF caused by race between ptdump and vmap pgtable
freeing&amp;#34;, v6.&lt;/p&gt;
&lt;p&gt;Kernel page table walkers fall into two broad categories - those ranges
where no exclusion is required via walk_kernel_page_table_range_lockless()
and those where exclusion is required via walk_kernel_page_table_range()
or walk_page_range_debug().&lt;/p&gt;
&lt;p&gt;The former category is used only by arm64 arch code operating on ranges it
both wholly owns and does not concurrently write.&lt;/p&gt;
&lt;p&gt;The latter category consists of kernel page table walkers operating on
ranges that are wholly owned (but which need exclusion against concurrent
writers).&lt;/p&gt;
&lt;p&gt;The lock used for exclusion is the mmap lock, and for kernel ranges this
is the mmap lock on init_mm.&lt;/p&gt;
&lt;p&gt;ptdump is a special case being both the only user of
walk_page_range_debug(), and the only case in which it walks ranges it
does not own.&lt;/p&gt;
&lt;p&gt;This presents a problem, as page tables may be freed under ptdump.  And
indeed there is a use-after-free bug in the kernel as a result, which this
series addresses.&lt;/p&gt;
&lt;p&gt;vmap promotes page tables to huge leaf entries where possible, freeing the
lower page table when it does.  It does this with no meaningful locks held
against concurrent ptdump walks.&lt;/p&gt;
&lt;p&gt;As a result, use-after-free can currently occur.  This series addresses
the issue by having the vmap huge promotion logic acquire the mmap read
lock whi…&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;mm/vmalloc: acquire init_mm lock on huge vmap to avoid ptdump UAF&lt;/p&gt;
&lt;p&gt;Patch series &amp;#34;mm: fix UAF caused by race between ptdump and vmap pgtable
freeing&amp;#34;, v6.&lt;/p&gt;
&lt;p&gt;Kernel page table walkers fall into two broad categories - those ranges
where no exclusion is required via walk_kernel_page_table_range_lockless()
and those where exclusion is required via walk_kernel_page_table_range()
or walk_page_range_debug().&lt;/p&gt;
&lt;p&gt;The former category is used only by arm64 arch code operating on ranges it
both wholly owns and does not concurrently write.&lt;/p&gt;
&lt;p&gt;The latter category consists of kernel page table walkers operating on
ranges that are wholly owned (but which need exclusion against concurrent
writers).&lt;/p&gt;
&lt;p&gt;The lock used for exclusion is the mmap lock, and for kernel ranges this
is the mmap lock on init_mm.&lt;/p&gt;
&lt;p&gt;ptdump is a special case being both the only user of
walk_page_range_debug(), and the only case in which it walks ranges it
does not own.&lt;/p&gt;
&lt;p&gt;This presents a problem, as page tables may be freed under ptdump.  And
indeed there is a use-after-free bug in the kernel as a result, which this
series addresses.&lt;/p&gt;
&lt;p&gt;vmap promotes page tables to huge leaf entries where possible, freeing the
lower page table when it does.  It does this with no meaningful locks held
against concurrent ptdump walks.&lt;/p&gt;
&lt;p&gt;As a result, use-after-free can currently occur.  This series addresses
the issue by having the vmap huge promotion logic acquire the mmap read
lock whi…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-74672</guid>
    </item>
  </channel>
</rss>
