<?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 19:10:57 +0000</lastBuildDate>
    <item>
      <title>CVE-2025-39992 — mm: swap: check for stable address space before operating on the VMA</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2025-39992</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: swap: check for stable address space before operating on the VMA&lt;/p&gt;
&lt;p&gt;It is possible to hit a zero entry while traversing the vmas in unuse_mm()
called from swapoff path and accessing it causes the OOPS:&lt;/p&gt;
&lt;p&gt;Unable to handle kernel NULL pointer dereference at virtual address
0000000000000446--&amp;gt; Loading the memory from offset 0x40 on the
XA_ZERO_ENTRY as address.
Mem abort info:
  ESR = 0x0000000096000005
  EC = 0x25: DABT (current EL), IL = 32 bits
  SET = 0, FnV = 0
  EA = 0, S1PTW = 0
  FSC = 0x05: level 1 translation fault&lt;/p&gt;
&lt;p&gt;The issue is manifested from the below race between the fork() on a
process and swapoff:
fork(dup_mmap())			swapoff(unuse_mm)
---------------                         -----------------
1) Identical mtree is built using
   __mt_dup().&lt;/p&gt;
&lt;p&gt;2) copy_pte_range()--&amp;gt;
	copy_nonpresent_pte():
       The dst mm is added into the
    mmlist to be visible to the
    swapoff operation.&lt;/p&gt;
&lt;p&gt;3) Fatal signal is sent to the parent
process(which is the current during the
fork) thus skip the duplication of the
vmas and mark the vma range with
XA_ZERO_ENTRY as a marker for this process
that helps during exit_mmap().&lt;/p&gt;
&lt;p&gt;4) swapoff is tried on the
					&amp;#39;mm&amp;#39; added to the &amp;#39;mmlist&amp;#39; as
					part of the 2.&lt;/p&gt;
&lt;p&gt;5) unuse_mm(), that iterates
					through the vma&amp;#39;s of this &amp;#39;mm&amp;#39;
					will hit the non-NULL zero entry
					and operating on this zero entry
					as a vma is resulting into the
					oops.&lt;/p&gt;
&lt;p&gt;The proper f…&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: swap: check for stable address space before operating on the VMA&lt;/p&gt;
&lt;p&gt;It is possible to hit a zero entry while traversing the vmas in unuse_mm()
called from swapoff path and accessing it causes the OOPS:&lt;/p&gt;
&lt;p&gt;Unable to handle kernel NULL pointer dereference at virtual address
0000000000000446--&amp;gt; Loading the memory from offset 0x40 on the
XA_ZERO_ENTRY as address.
Mem abort info:
  ESR = 0x0000000096000005
  EC = 0x25: DABT (current EL), IL = 32 bits
  SET = 0, FnV = 0
  EA = 0, S1PTW = 0
  FSC = 0x05: level 1 translation fault&lt;/p&gt;
&lt;p&gt;The issue is manifested from the below race between the fork() on a
process and swapoff:
fork(dup_mmap())			swapoff(unuse_mm)
---------------                         -----------------
1) Identical mtree is built using
   __mt_dup().&lt;/p&gt;
&lt;p&gt;2) copy_pte_range()--&amp;gt;
	copy_nonpresent_pte():
       The dst mm is added into the
    mmlist to be visible to the
    swapoff operation.&lt;/p&gt;
&lt;p&gt;3) Fatal signal is sent to the parent
process(which is the current during the
fork) thus skip the duplication of the
vmas and mark the vma range with
XA_ZERO_ENTRY as a marker for this process
that helps during exit_mmap().&lt;/p&gt;
&lt;p&gt;4) swapoff is tried on the
					&amp;#39;mm&amp;#39; added to the &amp;#39;mmlist&amp;#39; as
					part of the 2.&lt;/p&gt;
&lt;p&gt;5) unuse_mm(), that iterates
					through the vma&amp;#39;s of this &amp;#39;mm&amp;#39;
					will hit the non-NULL zero entry
					and operating on this zero entry
					as a vma is resulting into the
					oops.&lt;/p&gt;
&lt;p&gt;The proper f…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2025-39992</guid>
    </item>
  </channel>
</rss>
