CVE-2025-68809

In the Linux kernel, the following vulnerability has been resolved:

ksmbd: vfs: fix race on mflags in vfscache

ksmbd maintains delete-on-close and pending-delete state in ksmbdinode->mflags. In vfscache.c this field is accessed under inconsistent locking: some paths read and modify mflags under ci->m_lock while others do so without taking the lock at all.

Examples:

• ksmbdqueryinode_status() and __ksmbdinodeclose() use ci->mlock when checking or updating mflags.
• ksmbdinodependingdelete(), ksmbdsetinodependingdelete(), ksmbdclearinodependingdelete() and ksmbdfdsetdeleteonclose() used to read and modify mflags without ci->mlock.

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 ksmbdqueryinodestatus() look at mflags under ci->mlock after dropping inodehash_lock.
• Adding ci->mlock protection to all helpers that read or modify mflags (ksmbdinodependingdelete(), ksmbdsetinodependingdelete(), ksmbdclearinodependingdelete(), ksmbdfdsetdeleteonclose()).
• Keeping the existing ci->m_lock protection in __ksmbdinodeclose(), 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.