Cloudanix VulnDB

CVE-2025-68809

Critical · 9.1

CVSS

9.1

EPSS

0.5%

Published

Jan 13, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux kernel's file-sharing code can cause files to be deleted at the wrong time when many users access the same file at once, potentially leaving files behind or removing them unexpectedly.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Data Tampering
Component
OS kernel
Class
Race Condition
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Data race on ksmbd_inode->m_flags due to inconsistent use of ci->m_lock when reading or modifying delete-on-close and pending-delete bits across concurrent threads in vfs_cache.c.

Why it matters to the business

SMB file shares on affected Linux kernels may exhibit incorrect delete behavior, causing files to remain on disk after intended deletion or to vanish while still open, disrupting shared storage operations and data consistency.

How an attack unfolds

An attacker with SMB access opens, closes, and deletes the same file from multiple concurrent sessions or threads, racing the unprotected m_flags accesses to corrupt delete-on-close state and produce unexpected file persistence or premature removal.

How to fix it

Update the Linux kernel to the commit 5adad9727a815c26013b0d41cfee92ffa7d4037c or later stable release containing the unified ci->m_lock protection for all m_flags accesses.

How to confirm the fix worked

Confirm the patch is applied by verifying the presence of ci->m_lock around ksmbd_inode_pending_delete, ksmbd_set_inode_pending_delete, ksmbd_clear_inode_pending_delete, and ksmbd_fd_set_delete_on_close; recompile and boot-test with concurrent SMB delete workloads.

Typical attack path

  1. Establish multiple concurrent SMB sessions to the ksmbd server
  2. Open the same target file through different connections
  3. Issue overlapping close, delete, and pending-delete operations
  4. Trigger the unprotected m_flags reads/writes to lose or misobserve delete bits
  5. Observe resulting file either surviving delete-on-close or disappearing while still referenced

How to detect it

Review kernel logs and SMB audit trails for concurrent open/close/delete patterns on the same inode; look for ksmbd warnings or unexpected file state after delete operations in high-concurrency workloads.

What your security team should do

  • Prioritize kernel upgrade to the fixed commit on all systems running ksmbd
  • Temporarily disable ksmbd if the workload permits until patches are deployed
  • Monitor for unexpected file retention or disappearance on SMB shares as a behavioral indicator

The record

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 packages

Ecosystem Package Introduced Fixed
Linux Kernel 5.15.0 6.6.120
Mageia:9 kernel 0 6.6.120-1.mga9
Mageia:9 kernel-linus 0 6.6.120-1.mga9
Mageia:9 kmod-virtualbox 0 7.1.14-14.mga9
Mageia:9 kmod-xtables-addons 0 3.24-88.mga9

Related vulnerabilities