CVE-2026-31718
Use-After-Free in ksmbd Linux Kernel SMB Server
Publication date: 2026-05-01
Last updated on: 2026-05-03
Assigner: kernel.org
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| linux_kernel | ksmbd | * |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-UNKNOWN |
Attack-Flow Graph
AI Powered Q&A
How can this vulnerability impact me? :
This vulnerability in the Linux kernel's ksmbd component can cause a use-after-free error when handling durable file handles after a session disconnect. This can lead to memory corruption or crashes in the kernel, potentially causing system instability or denial of service.
What immediate steps should I take to mitigate this vulnerability?
The vulnerability is fixed in the Linux kernel by properly handling the lifetime of smb_lock->clist across three paths: safely skipping clist deletion when the list is empty and fp->conn is NULL, removing the lock from the old connection's lock_list in session_fd_check(), and re-adding the lock to the new connection's lock_list in ksmbd_reopen_durable_fd().
Therefore, the immediate mitigation step is to update your Linux kernel to a version that includes this fix.
Can you explain this vulnerability to me?
This vulnerability is a use-after-free issue in the Linux kernel's ksmbd component, specifically in the __ksmbd_close_fd() function related to durable file handles.
When a durable file handle survives a session disconnect (such as a TCP close without SMB2_LOGOFF), the system sets a connection pointer to NULL to preserve the handle for later reconnection. However, it fails to clean up byte-range locks associated with that handle.
Later, a scavenger thread attempts to clean up these locks but tries to access a connection object that has already been freed, causing a use-after-free error. This happens because the cleanup code tries to lock a spinlock on a NULL pointer, leading to accessing freed memory.
The root cause is asymmetric cleanup where lock entries remain dangling on a freed connection's lock list while the connection pointer is set to NULL. The fix involves properly managing the lifetime of these lock entries across different code paths to avoid accessing freed memory.