Skip to content
CVE Ledger
  • Newest CVEsPage
  • Recently added to KEVPage
  • Rising exploitation (EPSS)Page
  • Weekly digestPage
  • StatisticsPage
  • WatchlistPage
  • API docsPage
  • MCP serverPage
  • AboutPage
  • Data sourcesPage
  • Data statusPage
  • ChangelogPage
  • How it's builtPage
  • Support the projectPage

14 results

Back

CVE-2025-68809ksmbd: vfs: fix race on m_flags in vfs_cache

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.

Timeline

  1. ID reserved

    By Linux

  2. · 20 days later

    Published

  3. · 10 months later

    Record updated

Changes after publication (a new score, a public exploit, EPSS crossing 1, 10 or 50 %, leaving KEV) are kept since November 2026; earlier ones are not known.

Scores

CVSS scores of CVE-2025-68809, by who scored it
Scored byCVSSScoreVector
LinuxCNA (assigner)3.1Critical9.1CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H
NVDNVD · Deferred3.1Critical9.1CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H
EPSS (exploitation in 30 days)
0.53% · top 55% of all CVEs (13 Nov 2026)
Loading the EPSS history…

The list uses the assigner's score when there is one, then CISA's, then NVD's: Critical 9.1.

Affected products

  • Linux · Linux

    • affected f44158485826c076335d6860d35872271a83791d – < a4fd1fdf505facfae26b5654c9eff321f4cbc1a7
    • affected f44158485826c076335d6860d35872271a83791d – < 5adad9727a815c26013b0d41cfee92ffa7d4037c
    • affected f44158485826c076335d6860d35872271a83791d – < ccc78781041589ea383e61d5d7a1e9a31b210b93
    • affected f44158485826c076335d6860d35872271a83791d – < ee63729760f5b61a66f345c54dc4c7514e62383d
    • affected f44158485826c076335d6860d35872271a83791d – < 991f8a79db99b14c48d20d2052c82d65b9186cad
  • Linux · Linux

    • affected 5.15
    • unaffected < 5.15
    • unaffected 6.1.191 – ≤ 6.1.*
    • unaffected 6.6.120 – ≤ 6.6.*
    • unaffected 6.12.64 – ≤ 6.12.*
    • unaffected 6.18.3 – ≤ 6.18.*
    • unaffected 6.19 – ≤ *

References

References5

Sources

The same CVE in the primary databases and aggregators, to check against.

Badge for a README or a ticket

CVE-2025-68809 badge
[![CVE-2025-68809](https://cveledger.app/badge/CVE-2025-68809.svg)](https://cveledger.app/cve/CVE-2025-68809)

Record last updated .