| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <2026011311-CVE-2025-68809-e875@gregkh> Date: Tue, 13 Jan 2026 16:29:35 +0100 From: Greg Kroah-Hartman <gregkh@...uxfoundation.org> To: linux-cve-announce@...r.kernel.org Cc: Greg Kroah-Hartman <gregkh@...nel.org> Subject: CVE-2025-68809: ksmbd: vfs: fix race on m_flags in vfs_cache From: Greg Kroah-Hartman <gregkh@...nel.org> Description =========== In the Linux kernel, the following vulnerability has been resolved: ksmbd: vfs: fix race on m_flags in vfs_cache ksmbd maintains delete-on-close and pending-delete state in ksmbd_inode->m_flags. In vfs_cache.c this field is accessed under inconsistent locking: some paths read and modify m_flags under ci->m_lock while others do so without taking the lock at all. Examples: - ksmbd_query_inode_status() and __ksmbd_inode_close() use ci->m_lock when checking or updating m_flags. - ksmbd_inode_pending_delete(), ksmbd_set_inode_pending_delete(), ksmbd_clear_inode_pending_delete() and ksmbd_fd_set_delete_on_close() used to read and modify m_flags without ci->m_lock. This creates a potential data race on m_flags when multiple threads open, close and delete the same file concurrently. In the worst case delete-on-close and pending-delete bits can be lost or observed in an inconsistent state, leading to confusing delete semantics (files that stay on disk after delete-on-close, or files that disappear while still in use). Fix it by: - Making ksmbd_query_inode_status() look at m_flags under ci->m_lock after dropping inode_hash_lock. - Adding ci->m_lock protection to all helpers that read or modify m_flags (ksmbd_inode_pending_delete(), ksmbd_set_inode_pending_delete(), ksmbd_clear_inode_pending_delete(), ksmbd_fd_set_delete_on_close()). - Keeping the existing ci->m_lock protection in __ksmbd_inode_close(), and moving the actual unlink/xattr removal outside the lock. This unifies the locking around m_flags and removes the data race while preserving the existing delete-on-close behaviour. The Linux kernel CVE team has assigned CVE-2025-68809 to this issue. Affected and fixed versions =========================== Fixed in 6.6.120 with commit 5adad9727a815c26013b0d41cfee92ffa7d4037c Fixed in 6.12.64 with commit ccc78781041589ea383e61d5d7a1e9a31b210b93 Fixed in 6.18.3 with commit ee63729760f5b61a66f345c54dc4c7514e62383d Fixed in 6.19-rc1 with commit 991f8a79db99b14c48d20d2052c82d65b9186cad Please see https://www.kernel.org for a full list of currently supported kernel versions by the kernel community. Unaffected versions might change over time as fixes are backported to older supported kernel versions. The official CVE entry at https://cve.org/CVERecord/?id=CVE-2025-68809 will be updated if fixes are backported, please check that for the most up to date information about this issue. Affected files ============== The file(s) affected by this issue are: fs/smb/server/vfs_cache.c Mitigation ========== The Linux kernel CVE team recommends that you update to the latest stable kernel version for this, and many other bugfixes. Individual changes are never tested alone, but rather are part of a larger kernel release. Cherry-picking individual commits is not recommended or supported by the Linux kernel community at all. If however, updating to the latest release is impossible, the individual changes to resolve this issue can be found at these commits: https://git.kernel.org/stable/c/5adad9727a815c26013b0d41cfee92ffa7d4037c https://git.kernel.org/stable/c/ccc78781041589ea383e61d5d7a1e9a31b210b93 https://git.kernel.org/stable/c/ee63729760f5b61a66f345c54dc4c7514e62383d https://git.kernel.org/stable/c/991f8a79db99b14c48d20d2052c82d65b9186cad
Powered by blists - more mailing lists