<?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>Sat, 24 Oct 2026 04:52:45 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-98985 — namespace: check the mounts before reading their parents in pivot_root()</title>
      <link>https://db.gcve.eu/vuln/cve-2026-98985</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;namespace: check the mounts before reading their parents in pivot_root()&lt;/p&gt;
&lt;p&gt;path_pivot_root() reads the parents of new_root and of the caller&amp;#39;s root
and checks whether they are shared before it checks that either mount is
in the caller&amp;#39;s mount namespace. Only namespace_sem is held. That&amp;#39;s fine
for a mount that is in the caller&amp;#39;s mount namespace.&lt;/p&gt;
&lt;p&gt;But new_root can be a file descriptor to a mount that has been unmounted
and that only the file descriptor keeps alive. If that mount stayed
attached to its parent when it was unmounted nothing pins the parent for
it. The final mntput() of the parent unhooks the children under
mount_lock alone and frees the parent afterwards:&lt;/p&gt;
&lt;p&gt;pivot_root()                     close(fd), last ref on the parent
  ------------                     ---------------------------------
  ex_parent = new_mnt-&amp;gt;mnt_parent
                                   mntput_no_expire_slowpath()
                                     __umount_mnt(new_mnt)
                                   cleanup_mnt()
                                     call_rcu()
  IS_MNT_SHARED(ex_parent)&lt;/p&gt;
&lt;p&gt;BUG: KASAN: slab-use-after-free in path_pivot_root+0xf1a/0x1840
  Read of size 4 at addr ffff8881047382f8 by task pivot_widen/157
   path_pivot_root+0xf1a/0x1840
   __x64_sys_pivot_root+0x165/0x190&lt;/p&gt;
&lt;p&gt;The same goes for the caller&amp;#39;s root via chroot(). Both outcomes of the
check end in EINVAL so nothing but the read itself goes wrong.…&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;namespace: check the mounts before reading their parents in pivot_root()&lt;/p&gt;
&lt;p&gt;path_pivot_root() reads the parents of new_root and of the caller&amp;#39;s root
and checks whether they are shared before it checks that either mount is
in the caller&amp;#39;s mount namespace. Only namespace_sem is held. That&amp;#39;s fine
for a mount that is in the caller&amp;#39;s mount namespace.&lt;/p&gt;
&lt;p&gt;But new_root can be a file descriptor to a mount that has been unmounted
and that only the file descriptor keeps alive. If that mount stayed
attached to its parent when it was unmounted nothing pins the parent for
it. The final mntput() of the parent unhooks the children under
mount_lock alone and frees the parent afterwards:&lt;/p&gt;
&lt;p&gt;pivot_root()                     close(fd), last ref on the parent
  ------------                     ---------------------------------
  ex_parent = new_mnt-&amp;gt;mnt_parent
                                   mntput_no_expire_slowpath()
                                     __umount_mnt(new_mnt)
                                   cleanup_mnt()
                                     call_rcu()
  IS_MNT_SHARED(ex_parent)&lt;/p&gt;
&lt;p&gt;BUG: KASAN: slab-use-after-free in path_pivot_root+0xf1a/0x1840
  Read of size 4 at addr ffff8881047382f8 by task pivot_widen/157
   path_pivot_root+0xf1a/0x1840
   __x64_sys_pivot_root+0x165/0x190&lt;/p&gt;
&lt;p&gt;The same goes for the caller&amp;#39;s root via chroot(). Both outcomes of the
check end in EINVAL so nothing but the read itself goes wrong.…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/cve-2026-98985</guid>
    </item>
  </channel>
</rss>
