CVE-2025-68809
Awaiting Analysis Awaiting Analysis - Queue
BaseFortify

Publication date: 2026-01-13

Last updated on: 2026-01-14

Assigner: kernel.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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-01-13
Last Modified
2026-01-14
Generated
2026-05-27
AI Q&A
2026-01-14
EPSS Evaluated
2026-05-25
NVD
CVE-2025-68809
EUVD
EUVD-2026-2295
Affected Vendors & Products
Currently, no data is known.
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability is a race condition in the Linux kernel's ksmbd component related to inconsistent locking when accessing the m_flags field in ksmbd_inode. Different code paths either use or omit a lock (ci->m_lock) when reading or modifying m_flags, which can cause data races when multiple threads concurrently open, close, or delete the same file. This can lead to incorrect delete-on-close and pending-delete states, causing files to either remain on disk after deletion or disappear while still in use. The fix unifies locking around m_flags to prevent these races.


How can this vulnerability impact me? :

This vulnerability can cause files to behave unpredictably with respect to deletion: files that should be deleted on close might remain on disk, or files might disappear while still being used. This can lead to data inconsistency, confusion in file management, and potential data loss or unexpected file persistence.


What immediate steps should I take to mitigate this vulnerability?

To mitigate this vulnerability, update the Linux kernel to a version where the ksmbd component has been fixed to unify locking around m_flags in vfs_cache. This fix removes the data race condition by ensuring all accesses to m_flags are properly locked with ci->m_lock, preserving delete-on-close behavior and preventing inconsistent file delete semantics.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart