In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
fs\/ntfs3: use d_instantiate_new() in ntfs_create_inode() and murder syzbot’s “WARNING in do_new_mount” saga<\/p>\n
ntfs_create_inode() creates a new inode via ntfs_new_inode(). It hashes
\nit with insert_inode_locked() and so it’s marked as I_NEW until
\nunlock_new_inode().<\/p>\n
ntfs 3 calls d_instantiate() in between though… Since the dentry was
\nalready hashed by the lookup before the create any path walk finds it
\nwithout touching the parent’s i_rwsem and so can lock the inode.<\/p>\n
If the inode is a directory unlock_new_inode() calls
\nlockdep_annotate_inode_mutex_key() and marks i_rwsem with the
\ni_mutex_dir_key class.<\/p>\n
That resets the count and the owner of a lock somebody else may already
\nhold by now…<\/p>\n
syzbot has been spamming us with the same godforsaken bug<\/p>\n
“WARNING in do_new_mount”<\/p>\n
since 2023. I can’t take it anymore so I went looking. Afaict, syzbot’s
\nexecutor chdirs into a freshly mounted ntfs3 image, creates a
\ndirectory and then mounts some pseudofs on it. Everytime the mkdir()
\ntakes longer than syzbot waits mount() runs concurrently:<\/p>\n
mkdir(“.\/sys”) mount(NULL, “.\/sys”, “sysfs”)
\n ntfs_create_inode()
\n d_instantiate()
\n user_path_at() finds the dentry
\n do_lock_mount()
\n inode_lock(inode)
\n namespace_lock()
\n unlock_new_inode()
\n lockdep_annotate_inode_mutex_key()
\n init_rwsem(&inode->i_rwsem)
\n unlock_mount()
\n inode_unlock(inode)<\/p>\n
The mount side then releases a lock that according to the rwsem nobody
\nholds:<\/p>\n
DEBUG_RWSEMS_WARN_ON((rwsem_owner(sem) != current) && …):
\n count = 0x0, magic = 0xffff888043a854e8, owner = 0x0,
\n curr 0xffff888000244880, list empty
\n WARNING: CPU: 0 PID: 5346 at kernel\/locking\/rwsem.c:1368 __up_write
\n Call Trace:
\n inode_unlock include\/linux\/fs.h:877 [inline]
\n unlock_mount fs\/namespace.c:2892 [inline]
\n do_new_mount_fc fs\/namespace.c:3828 [inline]
\n do_new_mount+0x777\/0xa40 fs\/namespace.c:3887<\/p>\n
On PREEMPT_RT the same thing shows up as<\/p>\n
DEBUG_LOCKS_WARN_ON(rt_mutex_owner(lock) != current)
\n WARNING: kernel\/locking\/rtmutex_common.h:193 at rt_mutex_slowunlock<\/p>\n
The up_write() underflows the reset count. A following inode_lock() on
\nthat directory then never returns. A path walk into the new directory
\nracing with the mkdir() corrupts the lock the same way via
\ninode_lock_shared() in lookup_slow().<\/p>\n
Switch to d_instantiate_new() and drop the trailing unlock_new_inode().
\nAll error paths bail out before that point with I_NEW still set and
\nkeep using discard_new_inode().<\/p>\n
May we never see this fscking bug report again.<\/p>\n","protected":false},"excerpt":{"rendered":"
In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
fs\/ntfs3: use d_instantiate_new() in ntfs_create_inode() and murder syzbot’s “WARNING in do_new_mount” saga<\/p>\n
ntfs_create_inode() cr<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-41011","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/41011","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=41011"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=41011"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=41011"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}