---
id: CVE-2025-68809
title: 'ksmbd: vfs: fix race on m_flags in vfs_cache'
summary: |-
  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 un…
severity: critical
cvss: 9.1
cvssVector: 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H'
cvssSource: cna
vendor: Linux
product: Linux
affected:
  - >-
    Linux >= f44158485826c076335d6860d35872271a83791d <
    a4fd1fdf505facfae26b5654c9eff321f4cbc1a7
  - >-
    Linux >= f44158485826c076335d6860d35872271a83791d <
    5adad9727a815c26013b0d41cfee92ffa7d4037c
  - >-
    Linux >= f44158485826c076335d6860d35872271a83791d <
    ccc78781041589ea383e61d5d7a1e9a31b210b93
  - >-
    Linux >= f44158485826c076335d6860d35872271a83791d <
    ee63729760f5b61a66f345c54dc4c7514e62383d
  - >-
    Linux >= f44158485826c076335d6860d35872271a83791d <
    991f8a79db99b14c48d20d2052c82d65b9186cad
  - Linux 5.15
published: '2026-01-13'
updated: '2026-10-30'
sourceUpdated: '2026-10-30T12:23:20.102Z'
source: CVEORG
sourceUrl: 'https://www.cve.org/CVERecord?id=CVE-2025-68809'
references:
  - url: 'https://git.kernel.org/stable/c/a4fd1fdf505facfae26b5654c9eff321f4cbc1a7'
  - url: 'https://git.kernel.org/stable/c/5adad9727a815c26013b0d41cfee92ffa7d4037c'
  - url: 'https://git.kernel.org/stable/c/ccc78781041589ea383e61d5d7a1e9a31b210b93'
  - url: 'https://git.kernel.org/stable/c/ee63729760f5b61a66f345c54dc4c7514e62383d'
  - url: 'https://git.kernel.org/stable/c/991f8a79db99b14c48d20d2052c82d65b9186cad'
tags:
  - cve.org
epss: 0.00528
epssPercentile: 0.44947
ingestedAt: '2026-11-05T15:02:32.173Z'
---

## Overview

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.

## Affected

- `Linux >= f44158485826c076335d6860d35872271a83791d < a4fd1fdf505facfae26b5654c9eff321f4cbc1a7`
- `Linux >= f44158485826c076335d6860d35872271a83791d < 5adad9727a815c26013b0d41cfee92ffa7d4037c`
- `Linux >= f44158485826c076335d6860d35872271a83791d < ccc78781041589ea383e61d5d7a1e9a31b210b93`
- `Linux >= f44158485826c076335d6860d35872271a83791d < ee63729760f5b61a66f345c54dc4c7514e62383d`
- `Linux >= f44158485826c076335d6860d35872271a83791d < 991f8a79db99b14c48d20d2052c82d65b9186cad`
- `Linux 5.15`

## Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.