https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Thu, 12 Nov 2026 08:09:43 +0000 https://db.gcve.eu/vuln/cve-2026-98539 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>fs/ntfs3: use d_instantiate_new() in ntfs_create_inode() and murder syzbot&#39;s &#34;WARNING in do_new_mount&#34; saga</p> <p>ntfs_create_inode() creates a new inode via ntfs_new_inode(). It hashes it with insert_inode_locked() and so it&#39;s marked as I_NEW until unlock_new_inode().</p> <p>ntfs 3 calls d_instantiate() in between though... Since the dentry was already hashed by the lookup before the create any path walk finds it without touching the parent&#39;s i_rwsem and so can lock the inode.</p> <p>If the inode is a directory unlock_new_inode() calls lockdep_annotate_inode_mutex_key() and marks i_rwsem with the i_mutex_dir_key class.</p> <p>That resets the count and the owner of a lock somebody else may already hold by now...</p> <p>syzbot has been spamming us with the same godforsaken bug</p> <p>&#34;WARNING in do_new_mount&#34;</p> <p>since 2023. I can&#39;t take it anymore so I went looking. Afaict, syzbot&#39;s executor chdirs into a freshly mounted ntfs3 image, creates a directory and then mounts some pseudofs on it. Everytime the mkdir() takes longer than syzbot waits mount() runs concurrently:</p> <p>mkdir(&#34;./sys&#34;) mount(NULL, &#34;./sys&#34;, &#34;sysfs&#34;) ntfs_create_inode() d_instantiate() user_path_at() finds the dentry do_lock_mount() inode_lock(inode) namespace_lock() unlock_new_inode(…</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>fs/ntfs3: use d_instantiate_new() in ntfs_create_inode() and murder syzbot&#39;s &#34;WARNING in do_new_mount&#34; saga</p> <p>ntfs_create_inode() creates a new inode via ntfs_new_inode(). It hashes it with insert_inode_locked() and so it&#39;s marked as I_NEW until unlock_new_inode().</p> <p>ntfs 3 calls d_instantiate() in between though... Since the dentry was already hashed by the lookup before the create any path walk finds it without touching the parent&#39;s i_rwsem and so can lock the inode.</p> <p>If the inode is a directory unlock_new_inode() calls lockdep_annotate_inode_mutex_key() and marks i_rwsem with the i_mutex_dir_key class.</p> <p>That resets the count and the owner of a lock somebody else may already hold by now...</p> <p>syzbot has been spamming us with the same godforsaken bug</p> <p>&#34;WARNING in do_new_mount&#34;</p> <p>since 2023. I can&#39;t take it anymore so I went looking. Afaict, syzbot&#39;s executor chdirs into a freshly mounted ntfs3 image, creates a directory and then mounts some pseudofs on it. Everytime the mkdir() takes longer than syzbot waits mount() runs concurrently:</p> <p>mkdir(&#34;./sys&#34;) mount(NULL, &#34;./sys&#34;, &#34;sysfs&#34;) ntfs_create_inode() d_instantiate() user_path_at() finds the dentry do_lock_mount() inode_lock(inode) namespace_lock() unlock_new_inode(…</p> https://db.gcve.eu/vuln/cve-2026-98539