https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 24 Oct 2026 06:39:03 +0000 https://db.gcve.eu/vuln/cve-2026-98981 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>namespace: unhash a dentry before detaching the mounts on it</p> <p>unlink(), rmdir() and rename() remove the entry from the filesystem, call detach_mounts() on the entry with the inode locked and then call d_delete() once the inode is unlocked.</p> <p>The thing is that between detach_mounts() and d_delete() the dentry is still hashed and positive. But after detach_mounts() nothing covers the dentry anymore. A lookup that finds this dentry in the dcache can uncover what the mounts hid.</p> <p>That&#39;s a problem when unlinking files or directories that are mountpoints in other mount namespaces. Everybody who had the underlying entry covered can race the detach_mount() call until d_delete() has run.</p> <p>The race window isn&#39;t all that small. It encompasses namespace_unlock() with a full synchronize_rcu_expedited() grace period and the inode_unlock() of the entry.</p> <p>In my experiments three walkers that kept trying read an overmounted file in 11938 of the 16140 unlinks that removed its mountpoint from a bind mount of the filesystem within a minute.</p> <p>Fun fact, d_invalidate() has the same ordering problem but gets it right. It unhashes the dentry first and detaches the mounts afterwards. Let&#39;s do the same in __detach_mounts():</p> <p>- A lookup that hasn&#39;t found the dentry yet misses it in the dcache and waits for the directory lock that the caller holds until the name is gone for good.</p> <p>- A lockless lookup that found it already fails the…</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>namespace: unhash a dentry before detaching the mounts on it</p> <p>unlink(), rmdir() and rename() remove the entry from the filesystem, call detach_mounts() on the entry with the inode locked and then call d_delete() once the inode is unlocked.</p> <p>The thing is that between detach_mounts() and d_delete() the dentry is still hashed and positive. But after detach_mounts() nothing covers the dentry anymore. A lookup that finds this dentry in the dcache can uncover what the mounts hid.</p> <p>That&#39;s a problem when unlinking files or directories that are mountpoints in other mount namespaces. Everybody who had the underlying entry covered can race the detach_mount() call until d_delete() has run.</p> <p>The race window isn&#39;t all that small. It encompasses namespace_unlock() with a full synchronize_rcu_expedited() grace period and the inode_unlock() of the entry.</p> <p>In my experiments three walkers that kept trying read an overmounted file in 11938 of the 16140 unlinks that removed its mountpoint from a bind mount of the filesystem within a minute.</p> <p>Fun fact, d_invalidate() has the same ordering problem but gets it right. It unhashes the dentry first and detaches the mounts afterwards. Let&#39;s do the same in __detach_mounts():</p> <p>- A lookup that hasn&#39;t found the dentry yet misses it in the dcache and waits for the directory lock that the caller holds until the name is gone for good.</p> <p>- A lockless lookup that found it already fails the…</p> https://db.gcve.eu/vuln/cve-2026-98981