CVE-2025-68809

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: vfs: fix race on m_flags in vfs_cache<br /> <br /> ksmbd maintains delete-on-close and pending-delete state in<br /> ksmbd_inode-&gt;m_flags. In vfs_cache.c this field is accessed under<br /> inconsistent locking: some paths read and modify m_flags under<br /> ci-&gt;m_lock while others do so without taking the lock at all.<br /> <br /> Examples:<br /> <br /> - ksmbd_query_inode_status() and __ksmbd_inode_close() use<br /> ci-&gt;m_lock when checking or updating m_flags.<br /> - ksmbd_inode_pending_delete(), ksmbd_set_inode_pending_delete(),<br /> ksmbd_clear_inode_pending_delete() and ksmbd_fd_set_delete_on_close()<br /> used to read and modify m_flags without ci-&gt;m_lock.<br /> <br /> This creates a potential data race on m_flags when multiple threads<br /> open, close and delete the same file concurrently. In the worst case<br /> delete-on-close and pending-delete bits can be lost or observed in an<br /> inconsistent state, leading to confusing delete semantics (files that<br /> stay on disk after delete-on-close, or files that disappear while still<br /> in use).<br /> <br /> Fix it by:<br /> <br /> - Making ksmbd_query_inode_status() look at m_flags under ci-&gt;m_lock<br /> after dropping inode_hash_lock.<br /> - Adding ci-&gt;m_lock protection to all helpers that read or modify<br /> m_flags (ksmbd_inode_pending_delete(), ksmbd_set_inode_pending_delete(),<br /> ksmbd_clear_inode_pending_delete(), ksmbd_fd_set_delete_on_close()).<br /> - Keeping the existing ci-&gt;m_lock protection in __ksmbd_inode_close(),<br /> and moving the actual unlink/xattr removal outside the lock.<br /> <br /> This unifies the locking around m_flags and removes the data race while<br /> preserving the existing delete-on-close behaviour.