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->mlock while others do so without taking the lock at all. Examples: - ksmbdqueryinodestatus() 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 mflags 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 inodehashlock. - Adding ci->mlock protection to all helpers that read or modify mflags (ksmbdinodependingdelete(), ksmbdsetinodependingdelete(), ksmbdclearinodependingdelete(), ksmbdfdsetdeleteonclose()). - Keeping the existing ci->mlock protection in _ksmbdinodeclose(), and moving the actual unlink/xattr removal outside the lock. This unifies the locking around mflags and removes the data race while preserving the existing delete-on-close behaviour.