VYPR
Unrated severityNVD Advisory· Published Jan 13, 2026· Updated Apr 15, 2026

CVE-2025-68809

CVE-2025-68809

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.

AI Insight

LLM-synthesized narrative grounded in this CVE's description and references.

Race condition in Linux ksmbd's vfs_cache on m_flags can lead to inconsistent delete semantics and potential data loss.

Vulnerability

In the Linux kernel's ksmbd (SMB server) implementation, a race condition exists in the vfs_cache component. The m_flags field in ksmbd_inode is used to track delete-on-close and pending-delete state. However, some code paths access and modify m_flags without proper locking, while others use the ci->m_lock spinlock. This inconsistent locking creates a data race when multiple threads concurrently open, close, or delete the same file [1].

Exploitation

The race can be triggered by an attacker with the ability to perform concurrent file operations over SMB. Specifically, operations that set or clear delete-on-close and pending-delete flags (such as ksmbd_inode_pending_delete(), ksmbd_set_inode_pending_delete(), ksmbd_clear_inode_pending_delete(), and ksmbd_fd_set_delete_on_close()) were previously unprotected by the ci->m_lock [2]. This allows an attacker to cause the flags to be observed in an inconsistent state or lost entirely.

Impact

A successful exploitation of this race condition can result in confusing delete semantics. Files that should be deleted on close may remain on disk, or files that are still in use may be deleted prematurely. In worst-case scenarios, this could lead to data corruption or denial of service for SMB clients.

Mitigation

The vulnerability is fixed in Linux kernel commits that add consistent ci->m_lock protection to all m_flags accesses [1][2]. The fix also ensures that actual unlink and xattr removal operations are performed outside the lock to avoid deadlocks. Users should update to a kernel version containing the fix. As of publication, the vulnerability has not been listed in CISA's Known Exploited Vulnerabilities (KEV) catalog.

AI Insight generated on May 19, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.

Affected products

1

Patches

0

No patches discovered yet.

Vulnerability mechanics

AI mechanics synthesis has not run for this CVE yet.

References

4

News mentions

0

No linked articles in our index yet.