CVE-2025-68809

ksmbd: vfs: fix race on m_flags in vfs_cache

Published Jan 13, 2026 CVSS 3.1 · 9.1 Critical EPSS < 1% KEV · Not listed
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.

Analysis

No analysis available yet

Remediation

No remediation available yet

Tracking

Sign in to view the affected projects.

Advisories

Source ID Title
Debian DSA Debian DSA DSA-6126-1 linux security update
Ubuntu USN Ubuntu USN USN-8177-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-8179-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-8177-2 Linux kernel (Real-time) vulnerabilities
Ubuntu USN Ubuntu USN USN-8183-1 Linux kernel (GCP) vulnerabilities
Ubuntu USN Ubuntu USN USN-8184-1 Linux kernel (Real-time) vulnerabilities
Ubuntu USN Ubuntu USN USN-8179-2 Linux kernel (FIPS) vulnerabilities
Ubuntu USN Ubuntu USN USN-8185-1 Linux kernel (NVIDIA) vulnerabilities
Ubuntu USN Ubuntu USN USN-8179-3 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-8183-2 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-8203-1 Linux kernel (Oracle) vulnerabilities
Ubuntu USN Ubuntu USN USN-8204-1 Linux kernel (Raspberry Pi Real-time) vulnerabilities
Ubuntu USN Ubuntu USN USN-8185-2 Linux kernel (Low Latency NVIDIA) vulnerabilities
Ubuntu USN Ubuntu USN USN-8179-4 Linux kernel (GCP) vulnerabilities
Ubuntu USN Ubuntu USN USN-8245-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-8257-1 Linux kernel (Raspberry Pi) vulnerabilities
Ubuntu USN Ubuntu USN USN-8258-1 Linux kernel (Azure) vulnerabilities
Ubuntu USN Ubuntu USN USN-8260-1 Linux kernel (Azure FIPS) vulnerabilities
Ubuntu USN Ubuntu USN USN-8261-1 Linux kernel (Xilinx) vulnerabilities
Ubuntu USN Ubuntu USN USN-8265-1 Linux kernel (NVIDIA Tegra) vulnerabilities
Ubuntu USN Ubuntu USN USN-8440-1 Linux kernel (Azure) vulnerabilities
History
Type Values Removed Values Added
Metrics cvssV3_1

{'score': 9.1, 'vector': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H'}

Type Values Removed Values Added
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.
Title ksmbd: vfs: fix race on m_flags in vfs_cache
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References
Weaknesses

No weakness.

Sources

Status
PUBLISHED
Assigner
Linux
Published
Updated
Oct 30, 2026, 12:23 PM
Reserved
Dec 24, 2025, 10:30 AM
Status
Deferred
Published
Jan 13, 2026, 4:16 PM
Modified
Oct 30, 2026, 1:18 PM
Severity
Moderate
Public date
Jan 13, 2026, 12:00 AM