<?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>Tue, 10 Nov 2026 01:02:45 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-99170</title>
      <link>https://db.gcve.eu/vuln/fkie_cve-2026-99170</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;namespace: a mount that copy_tree() leaves out can&amp;#39;t take over a lock&lt;/p&gt;
&lt;p&gt;Since commit c62a4766937e (&amp;#34;move_mount: transfer MNT_LOCKED&amp;#34;) a mount
can be moved beneath a locked mount. The lock moves from the old cover
to the new mount which takes over the job of hiding what&amp;#39;s under it and
the old cover can be unmounted. That works as long as the new mount
stays. But the caller picks the new mount and copy_tree() leaves a
mount of a mount namespace file out of every copy made without
CL_COPY_MNT_NS_FILE, together with everything mounted on it, and never
looks at MNT_LOCKED. unshare(CLONE_NEWNS) and mount propagation make
such copies.&lt;/p&gt;
&lt;p&gt;So a task that is root in its own user namespace gets rid of a locked
cover on a file without a race and without touching the filesystem
below it. It makes a child with a mount namespace of its own, binds the
child&amp;#39;s /proc/&amp;lt;pid&amp;gt;/ns/mnt beneath the cover with MOVE_MOUNT_BENEATH,
which hands the lock to that bind, and calls unshare(CLONE_NEWNS). The
new mount namespace has nothing on the file. That&amp;#39;s the usual way to
mask a single file, a bind of /dev/null or of an empty file. With a
bind of an ordinary file the file stays covered.&lt;/p&gt;
&lt;p&gt;copy_tree() already refuses to leave out a locked unbindable mount with
-EPERM since commit df7342b24018 (&amp;#34;mount: Don&amp;#39;t allow copying
MNT_UNBINDABLE|MNT_LOCKED mounts&amp;#34;). Do the same for a locked mount of a
mount namespace file. That also covers a tree copie…&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: a mount that copy_tree() leaves out can&amp;#39;t take over a lock&lt;/p&gt;
&lt;p&gt;Since commit c62a4766937e (&amp;#34;move_mount: transfer MNT_LOCKED&amp;#34;) a mount
can be moved beneath a locked mount. The lock moves from the old cover
to the new mount which takes over the job of hiding what&amp;#39;s under it and
the old cover can be unmounted. That works as long as the new mount
stays. But the caller picks the new mount and copy_tree() leaves a
mount of a mount namespace file out of every copy made without
CL_COPY_MNT_NS_FILE, together with everything mounted on it, and never
looks at MNT_LOCKED. unshare(CLONE_NEWNS) and mount propagation make
such copies.&lt;/p&gt;
&lt;p&gt;So a task that is root in its own user namespace gets rid of a locked
cover on a file without a race and without touching the filesystem
below it. It makes a child with a mount namespace of its own, binds the
child&amp;#39;s /proc/&amp;lt;pid&amp;gt;/ns/mnt beneath the cover with MOVE_MOUNT_BENEATH,
which hands the lock to that bind, and calls unshare(CLONE_NEWNS). The
new mount namespace has nothing on the file. That&amp;#39;s the usual way to
mask a single file, a bind of /dev/null or of an empty file. With a
bind of an ordinary file the file stays covered.&lt;/p&gt;
&lt;p&gt;copy_tree() already refuses to leave out a locked unbindable mount with
-EPERM since commit df7342b24018 (&amp;#34;mount: Don&amp;#39;t allow copying
MNT_UNBINDABLE|MNT_LOCKED mounts&amp;#34;). Do the same for a locked mount of a
mount namespace file. That also covers a tree copie…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/fkie_cve-2026-99170</guid>
    </item>
    <item>
      <title>GHSA-fv9w-c66r-mfvr</title>
      <link>https://db.gcve.eu/vuln/ghsa-fv9w-c66r-mfvr</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;namespace: a mount that copy_tree() leaves out can&amp;#39;t take over a lock&lt;/p&gt;
&lt;p&gt;Since commit c62a4766937e (&amp;#34;move_mount: transfer MNT_LOCKED&amp;#34;) a mount
can be moved beneath a locked mount. The lock moves from the old cover
to the new mount which takes over the job of hiding what&amp;#39;s under it and
the old cover can be unmounted. That works as long as the new mount
stays. But the caller picks the new mount and copy_tree() leaves a
mount of a mount namespace file out of every copy made without
CL_COPY_MNT_NS_FILE, together with everything mounted on it, and never
looks at MNT_LOCKED. unshare(CLONE_NEWNS) and mount propagation make
such copies.&lt;/p&gt;
&lt;p&gt;So a task that is root in its own user namespace gets rid of a locked
cover on a file without a race and without touching the filesystem
below it. It makes a child with a mount namespace of its own, binds the
child&amp;#39;s /proc/&amp;lt;pid&amp;gt;/ns/mnt beneath the cover with MOVE_MOUNT_BENEATH,
which hands the lock to that bind, and calls unshare(CLONE_NEWNS). The
new mount namespace has nothing on the file. That&amp;#39;s the usual way to
mask a single file, a bind of /dev/null or of an empty file. With a
bind of an ordinary file the file stays covered.&lt;/p&gt;
&lt;p&gt;copy_tree() already refuses to leave out a locked unbindable mount with
-EPERM since commit df7342b24018 (&amp;#34;mount: Don&amp;#39;t allow copying
MNT_UNBINDABLE|MNT_LOCKED mounts&amp;#34;). Do the same for a locked mount of a
mount namespace file. That also covers a tree copie…&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: a mount that copy_tree() leaves out can&amp;#39;t take over a lock&lt;/p&gt;
&lt;p&gt;Since commit c62a4766937e (&amp;#34;move_mount: transfer MNT_LOCKED&amp;#34;) a mount
can be moved beneath a locked mount. The lock moves from the old cover
to the new mount which takes over the job of hiding what&amp;#39;s under it and
the old cover can be unmounted. That works as long as the new mount
stays. But the caller picks the new mount and copy_tree() leaves a
mount of a mount namespace file out of every copy made without
CL_COPY_MNT_NS_FILE, together with everything mounted on it, and never
looks at MNT_LOCKED. unshare(CLONE_NEWNS) and mount propagation make
such copies.&lt;/p&gt;
&lt;p&gt;So a task that is root in its own user namespace gets rid of a locked
cover on a file without a race and without touching the filesystem
below it. It makes a child with a mount namespace of its own, binds the
child&amp;#39;s /proc/&amp;lt;pid&amp;gt;/ns/mnt beneath the cover with MOVE_MOUNT_BENEATH,
which hands the lock to that bind, and calls unshare(CLONE_NEWNS). The
new mount namespace has nothing on the file. That&amp;#39;s the usual way to
mask a single file, a bind of /dev/null or of an empty file. With a
bind of an ordinary file the file stays covered.&lt;/p&gt;
&lt;p&gt;copy_tree() already refuses to leave out a locked unbindable mount with
-EPERM since commit df7342b24018 (&amp;#34;mount: Don&amp;#39;t allow copying
MNT_UNBINDABLE|MNT_LOCKED mounts&amp;#34;). Do the same for a locked mount of a
mount namespace file. That also covers a tree copie…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-fv9w-c66r-mfvr</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-99170</title>
      <link>https://db.gcve.eu/vuln/ubuntu-cve-2026-99170</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 105 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: namespace: a mount that copy_tree() leaves out can&amp;#39;t take over a lock Since commit c62a4766937e (&amp;#34;move_mount: transfer MNT_LOCKED&amp;#34;) a mount can be moved beneath a locked mount. The lock moves from the old cover to the new mount which takes over the job of hiding what&amp;#39;s under it and the old cover can be unmounted. That works as long as the new mount stays. But the caller picks the new mount and copy_tree() leaves a mount of a mount namespace file out of every copy made without CL_COPY_MNT_NS_FILE, together with everything mounted on it, and never looks at MNT_LOCKED. unshare(CLONE_NEWNS) and mount propagation make such copies. So a task that is root in its own user namespace gets rid of a locked cover on a file without a race and without touching the filesystem below it. It makes a child with a mount namespace of its own, binds the child&amp;#39;s /proc/&amp;lt;pid&amp;gt;/ns/mnt beneath the cover with MOVE_MOUNT_BENEATH, which hands the lock to that bind, and calls unshare(CLONE_NEWNS). The new mount namespace has nothing on the file. That&amp;#39;s the usual way to mask a single file, a bind of /dev/null or of an empty file. With a bind of an ordinary file the file stays covered. copy_tree() already refuses to leave out a locked unbindable mount with -EPERM since commit df7342b24018 (&amp;#34;mount: Don&amp;#39;t allow copying MNT_UNBINDABLE|MNT_LOCKED mounts&amp;#34;). Do the same for a locked mount of a mount namespace file. That also covers a tree copied wi…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 105 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: namespace: a mount that copy_tree() leaves out can&amp;#39;t take over a lock Since commit c62a4766937e (&amp;#34;move_mount: transfer MNT_LOCKED&amp;#34;) a mount can be moved beneath a locked mount. The lock moves from the old cover to the new mount which takes over the job of hiding what&amp;#39;s under it and the old cover can be unmounted. That works as long as the new mount stays. But the caller picks the new mount and copy_tree() leaves a mount of a mount namespace file out of every copy made without CL_COPY_MNT_NS_FILE, together with everything mounted on it, and never looks at MNT_LOCKED. unshare(CLONE_NEWNS) and mount propagation make such copies. So a task that is root in its own user namespace gets rid of a locked cover on a file without a race and without touching the filesystem below it. It makes a child with a mount namespace of its own, binds the child&amp;#39;s /proc/&amp;lt;pid&amp;gt;/ns/mnt beneath the cover with MOVE_MOUNT_BENEATH, which hands the lock to that bind, and calls unshare(CLONE_NEWNS). The new mount namespace has nothing on the file. That&amp;#39;s the usual way to mask a single file, a bind of /dev/null or of an empty file. With a bind of an ordinary file the file stays covered. copy_tree() already refuses to leave out a locked unbindable mount with -EPERM since commit df7342b24018 (&amp;#34;mount: Don&amp;#39;t allow copying MNT_UNBINDABLE|MNT_LOCKED mounts&amp;#34;). Do the same for a locked mount of a mount namespace file. That also covers a tree copied wi…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ubuntu-cve-2026-99170</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-4224 — Linux Kernel: Mehrere Schwachstellen ermöglichen nicht spezifizierten Angriff</title>
      <link>https://db.gcve.eu/vuln/wid-sec-w-2026-4224</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen, möglicherweise einen Denial-of-Service-Angriff auszulösen, Daten zu manipulieren oder offenzulegen oder Sicherheitsmaßnahmen zu umgehen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen, möglicherweise einen Denial-of-Service-Angriff auszulösen, Daten zu manipulieren oder offenzulegen oder Sicherheitsmaßnahmen zu umgehen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/wid-sec-w-2026-4224</guid>
    </item>
  </channel>
</rss>
