https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 10 Nov 2026 01:34:04 +0000 https://db.gcve.eu/vuln/cve-2026-99170 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>namespace: a mount that copy_tree() leaves out can&#39;t take over a lock</p> <p>Since commit c62a4766937e (&#34;move_mount: transfer MNT_LOCKED&#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&#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.</p> <p>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&#39;s /proc/&lt;pid&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&#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.</p> <p>copy_tree() already refuses to leave out a locked unbindable mount with -EPERM since commit df7342b24018 (&#34;mount: Don&#39;t allow copying MNT_UNBINDABLE|MNT_LOCKED mounts&#34;). Do the same for a locked mount of a mount namespace file. That also covers a tree copie…</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>namespace: a mount that copy_tree() leaves out can&#39;t take over a lock</p> <p>Since commit c62a4766937e (&#34;move_mount: transfer MNT_LOCKED&#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&#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.</p> <p>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&#39;s /proc/&lt;pid&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&#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.</p> <p>copy_tree() already refuses to leave out a locked unbindable mount with -EPERM since commit df7342b24018 (&#34;mount: Don&#39;t allow copying MNT_UNBINDABLE|MNT_LOCKED mounts&#34;). Do the same for a locked mount of a mount namespace file. That also covers a tree copie…</p> https://db.gcve.eu/vuln/cve-2026-99170