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.
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.
Published:
2026-01-13
Score:
n/a
EPSS:
< 1% Very Low
KEV:
No
Impact:
n/a
Action:
n/a
Analysis and contextual insights are available on OpenCVE Cloud.
Remediation
No vendor fix or workaround currently provided.
Additional remediation guidance may be available on OpenCVE Cloud.
Tracking
Sign in to view the affected projects.
Advisories
| Source | ID | Title |
|---|---|---|
Debian DSA |
DSA-6126-1 | linux security update |
Ubuntu USN |
USN-8177-1 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-8179-1 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-8177-2 | Linux kernel (Real-time) vulnerabilities |
Ubuntu USN |
USN-8183-1 | Linux kernel (GCP) vulnerabilities |
Ubuntu USN |
USN-8184-1 | Linux kernel (Real-time) vulnerabilities |
Ubuntu USN |
USN-8179-2 | Linux kernel (FIPS) vulnerabilities |
Ubuntu USN |
USN-8185-1 | Linux kernel (NVIDIA) vulnerabilities |
Ubuntu USN |
USN-8179-3 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-8183-2 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-8203-1 | Linux kernel (Oracle) vulnerabilities |
Ubuntu USN |
USN-8204-1 | Linux kernel (Raspberry Pi Real-time) vulnerabilities |
Ubuntu USN |
USN-8185-2 | Linux kernel (Low Latency NVIDIA) vulnerabilities |
Ubuntu USN |
USN-8179-4 | Linux kernel (GCP) vulnerabilities |
Ubuntu USN |
USN-8245-1 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-8257-1 | Linux kernel (Raspberry Pi) vulnerabilities |
Ubuntu USN |
USN-8258-1 | Linux kernel (Azure) vulnerabilities |
Ubuntu USN |
USN-8260-1 | Linux kernel (Azure FIPS) vulnerabilities |
Ubuntu USN |
USN-8261-1 | Linux kernel (Xilinx) vulnerabilities |
Ubuntu USN |
USN-8265-1 | Linux kernel (NVIDIA Tegra) vulnerabilities |
References
History
Thu, 15 Jan 2026 12:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| References |
| |
| Metrics |
threat_severity
|
threat_severity
|
Tue, 13 Jan 2026 15:45:00 +0000
| 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 |
|
Status: PUBLISHED
Assigner: Linux
Published:
Updated: 2026-05-11T21:53:45.694Z
Reserved: 2025-12-24T10:30:51.047Z
Link: CVE-2025-68809
No data.
Status : Deferred
Published: 2026-01-13T16:16:03.080
Modified: 2026-04-15T00:35:42.020
Link: CVE-2025-68809
OpenCVE Enrichment
No data.
Weaknesses
No weakness.
Debian DSA
Ubuntu USN