<?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>Mon, 28 Sep 2026 23:15:57 +0000</lastBuildDate>
    <item>
      <title>CVE-2024-46787 — userfaultfd: fix checks for huge PMDs</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2024-46787</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;userfaultfd: fix checks for huge PMDs&lt;/p&gt;
&lt;p&gt;Patch series &amp;#34;userfaultfd: fix races around pmd_trans_huge() check&amp;#34;, v2.&lt;/p&gt;
&lt;p&gt;The pmd_trans_huge() code in mfill_atomic() is wrong in three different
ways depending on kernel version:&lt;/p&gt;
&lt;p&gt;1. The pmd_trans_huge() check is racy and can lead to a BUG_ON() (if you hit
   the right two race windows) - I&amp;#39;ve tested this in a kernel build with
   some extra mdelay() calls. See the commit message for a description
   of the race scenario.
   On older kernels (before 6.5), I think the same bug can even
   theoretically lead to accessing transhuge page contents as a page table
   if you hit the right 5 narrow race windows (I haven&amp;#39;t tested this case).
2. As pointed out by Qi Zheng, pmd_trans_huge() is not sufficient for
   detecting PMDs that don&amp;#39;t point to page tables.
   On older kernels (before 6.5), you&amp;#39;d just have to win a single fairly
   wide race to hit this.
   I&amp;#39;ve tested this on 6.1 stable by racing migration (with a mdelay()
   patched into try_to_migrate()) against UFFDIO_ZEROPAGE - on my x86
   VM, that causes a kernel oops in ptlock_ptr().
3. On newer kernels (&amp;gt;=6.5), for shmem mappings, khugepaged is allowed
   to yank page tables out from under us (though I haven&amp;#39;t tested that),
   so I think the BUG_ON() checks in mfill_atomic() are just wrong.&lt;/p&gt;
&lt;p&gt;I decided to write two separate fixes for these (one fix for bugs 1+2, one
fix for bug 3), so that the first fix can be backp…&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;userfaultfd: fix checks for huge PMDs&lt;/p&gt;
&lt;p&gt;Patch series &amp;#34;userfaultfd: fix races around pmd_trans_huge() check&amp;#34;, v2.&lt;/p&gt;
&lt;p&gt;The pmd_trans_huge() code in mfill_atomic() is wrong in three different
ways depending on kernel version:&lt;/p&gt;
&lt;p&gt;1. The pmd_trans_huge() check is racy and can lead to a BUG_ON() (if you hit
   the right two race windows) - I&amp;#39;ve tested this in a kernel build with
   some extra mdelay() calls. See the commit message for a description
   of the race scenario.
   On older kernels (before 6.5), I think the same bug can even
   theoretically lead to accessing transhuge page contents as a page table
   if you hit the right 5 narrow race windows (I haven&amp;#39;t tested this case).
2. As pointed out by Qi Zheng, pmd_trans_huge() is not sufficient for
   detecting PMDs that don&amp;#39;t point to page tables.
   On older kernels (before 6.5), you&amp;#39;d just have to win a single fairly
   wide race to hit this.
   I&amp;#39;ve tested this on 6.1 stable by racing migration (with a mdelay()
   patched into try_to_migrate()) against UFFDIO_ZEROPAGE - on my x86
   VM, that causes a kernel oops in ptlock_ptr().
3. On newer kernels (&amp;gt;=6.5), for shmem mappings, khugepaged is allowed
   to yank page tables out from under us (though I haven&amp;#39;t tested that),
   so I think the BUG_ON() checks in mfill_atomic() are just wrong.&lt;/p&gt;
&lt;p&gt;I decided to write two separate fixes for these (one fix for bugs 1+2, one
fix for bug 3), so that the first fix can be backp…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2024-46787</guid>
    </item>
  </channel>
</rss>
