<?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 16:58:31 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-98989</title>
      <link>https://db.gcve.eu/vuln/fkie_cve-2026-98989</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;namespace: check a recursive bind mount for mount namespace loops&lt;/p&gt;
&lt;p&gt;do_loopback() refuses to bind mount the file of a mount namespace that
is as old as the caller&amp;#39;s or older because a mount namespace that holds
a mount of its own file, or of an ancestor&amp;#39;s, would cause a cycle. But
it only checks the dentry the bind mount starts from. With MS_REC
everything below it is copied and do_loopback() passes
CL_COPY_MNT_NS_FILE so mount namespace files below the source are
copied.&lt;/p&gt;
&lt;p&gt;That&amp;#39;s fine for a source in the caller&amp;#39;s own mount namespace. Every
mount namespace file in there passed the same check when it was
bind-mounted. It isn&amp;#39;t fine for a source in another mount namespace.
may_copy_tree() accepts a bind mount of any nsfs or pidfs file no matter
what mount namespace it lives in so that /proc/&amp;lt;pid&amp;gt;/ns/&amp;lt;ns&amp;gt; and pidfds
can be bind mounted. If we create a bind-mount stack of mount namespaces
file descriptors the kernel will copy them irrespective of their
ancestoral relationship to the mount namespace in question:&lt;/p&gt;
&lt;p&gt;151 146 0:7 net:[4026531833] /tmp/nrc/y rw - nsfs nsfs rw
  152 151 0:7 mnt:[4026532293] /tmp/nrc/y rw - nsfs nsfs rw&lt;/p&gt;
&lt;p&gt;Mount 152 is a mount of the mount namespace file of mount namespace
4026532293 inside mount namespace 4026532293. That namespace and every
mount in it are leaked... All it takes is a process in an older mount
namespace that stacks the file and repeating it leaks without limit:&lt;/p&gt;
&lt;p&gt;after…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;namespace: check a recursive bind mount for mount namespace loops&lt;/p&gt;
&lt;p&gt;do_loopback() refuses to bind mount the file of a mount namespace that
is as old as the caller&amp;#39;s or older because a mount namespace that holds
a mount of its own file, or of an ancestor&amp;#39;s, would cause a cycle. But
it only checks the dentry the bind mount starts from. With MS_REC
everything below it is copied and do_loopback() passes
CL_COPY_MNT_NS_FILE so mount namespace files below the source are
copied.&lt;/p&gt;
&lt;p&gt;That&amp;#39;s fine for a source in the caller&amp;#39;s own mount namespace. Every
mount namespace file in there passed the same check when it was
bind-mounted. It isn&amp;#39;t fine for a source in another mount namespace.
may_copy_tree() accepts a bind mount of any nsfs or pidfs file no matter
what mount namespace it lives in so that /proc/&amp;lt;pid&amp;gt;/ns/&amp;lt;ns&amp;gt; and pidfds
can be bind mounted. If we create a bind-mount stack of mount namespaces
file descriptors the kernel will copy them irrespective of their
ancestoral relationship to the mount namespace in question:&lt;/p&gt;
&lt;p&gt;151 146 0:7 net:[4026531833] /tmp/nrc/y rw - nsfs nsfs rw
  152 151 0:7 mnt:[4026532293] /tmp/nrc/y rw - nsfs nsfs rw&lt;/p&gt;
&lt;p&gt;Mount 152 is a mount of the mount namespace file of mount namespace
4026532293 inside mount namespace 4026532293. That namespace and every
mount in it are leaked... All it takes is a process in an older mount
namespace that stacks the file and repeating it leaks without limit:&lt;/p&gt;
&lt;p&gt;after…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/fkie_cve-2026-98989</guid>
    </item>
    <item>
      <title>GHSA-88xj-3p4j-2c73</title>
      <link>https://db.gcve.eu/vuln/ghsa-88xj-3p4j-2c73</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;namespace: check a recursive bind mount for mount namespace loops&lt;/p&gt;
&lt;p&gt;do_loopback() refuses to bind mount the file of a mount namespace that
is as old as the caller&amp;#39;s or older because a mount namespace that holds
a mount of its own file, or of an ancestor&amp;#39;s, would cause a cycle. But
it only checks the dentry the bind mount starts from. With MS_REC
everything below it is copied and do_loopback() passes
CL_COPY_MNT_NS_FILE so mount namespace files below the source are
copied.&lt;/p&gt;
&lt;p&gt;That&amp;#39;s fine for a source in the caller&amp;#39;s own mount namespace. Every
mount namespace file in there passed the same check when it was
bind-mounted. It isn&amp;#39;t fine for a source in another mount namespace.
may_copy_tree() accepts a bind mount of any nsfs or pidfs file no matter
what mount namespace it lives in so that /proc/&amp;lt;pid&amp;gt;/ns/&amp;lt;ns&amp;gt; and pidfds
can be bind mounted. If we create a bind-mount stack of mount namespaces
file descriptors the kernel will copy them irrespective of their
ancestoral relationship to the mount namespace in question:&lt;/p&gt;
&lt;p&gt;151 146 0:7 net:[4026531833] /tmp/nrc/y rw - nsfs nsfs rw
  152 151 0:7 mnt:[4026532293] /tmp/nrc/y rw - nsfs nsfs rw&lt;/p&gt;
&lt;p&gt;Mount 152 is a mount of the mount namespace file of mount namespace
4026532293 inside mount namespace 4026532293. That namespace and every
mount in it are leaked... All it takes is a process in an older mount
namespace that stacks the file and repeating it leaks without limit:&lt;/p&gt;
&lt;p&gt;after…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;namespace: check a recursive bind mount for mount namespace loops&lt;/p&gt;
&lt;p&gt;do_loopback() refuses to bind mount the file of a mount namespace that
is as old as the caller&amp;#39;s or older because a mount namespace that holds
a mount of its own file, or of an ancestor&amp;#39;s, would cause a cycle. But
it only checks the dentry the bind mount starts from. With MS_REC
everything below it is copied and do_loopback() passes
CL_COPY_MNT_NS_FILE so mount namespace files below the source are
copied.&lt;/p&gt;
&lt;p&gt;That&amp;#39;s fine for a source in the caller&amp;#39;s own mount namespace. Every
mount namespace file in there passed the same check when it was
bind-mounted. It isn&amp;#39;t fine for a source in another mount namespace.
may_copy_tree() accepts a bind mount of any nsfs or pidfs file no matter
what mount namespace it lives in so that /proc/&amp;lt;pid&amp;gt;/ns/&amp;lt;ns&amp;gt; and pidfds
can be bind mounted. If we create a bind-mount stack of mount namespaces
file descriptors the kernel will copy them irrespective of their
ancestoral relationship to the mount namespace in question:&lt;/p&gt;
&lt;p&gt;151 146 0:7 net:[4026531833] /tmp/nrc/y rw - nsfs nsfs rw
  152 151 0:7 mnt:[4026532293] /tmp/nrc/y rw - nsfs nsfs rw&lt;/p&gt;
&lt;p&gt;Mount 152 is a mount of the mount namespace file of mount namespace
4026532293 inside mount namespace 4026532293. That namespace and every
mount in it are leaked... All it takes is a process in an older mount
namespace that stacks the file and repeating it leaks without limit:&lt;/p&gt;
&lt;p&gt;after…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-88xj-3p4j-2c73</guid>
    </item>
  </channel>
</rss>
