Answer in brief
CVE-2025-68809 records a Critical severity (CVSS 9.1) vulnerability in ksmbd: vfs: fix race on m_flags in vfs_cache. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 9.1. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=f44158485826c076335d6860d35872271a83791d <a4fd1fdf505facfae26b5654c9eff321f4cbc1a7 || >=f44158485826c076335d6860d35872271a83791d <5adad9727a815c26013b0d41cfee92ffa7d4037c || >=f44158485826c076335d6860d35872271a83791d <ccc78781041589ea383e61d5d7a1e9a31b210b93 || >=f44158485826c076335d6860d35872271a83791d <ee63729760f5b61a66f345c54dc4c7514e62383d || >=f44158485826c076335d6860d35872271a83791d <991f8a79db99b14c48d20d2052c82d65b9186cad | a4fd1fdf505facfae26b5654c9eff321f4cbc1a7, 5adad9727a815c26013b0d41cfee92ffa7d4037c, ccc78781041589ea383e61d5d7a1e9a31b210b93, ee63729760f5b61a66f345c54dc4c7514e62383d, 991f8a79db99b14c48d20d2052c82d65b9186cad |
| Linux/Linuxgeneric | 5.15 | Not reported |
Published upstream
Jan 13, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Oct 30, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Oct 30, 2026
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.
Quoted source text, attributed separately from HOL analysis.