CVE-2026-64396 in Linux
Summary
by MITRE • 07/25/2026
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix UAF of struct file_lock in SMB2_LOCK deferred-lock cancellation
When a blocking byte-range lock request is deferred in the FILE_LOCK_DEFERRED path, ksmbd registers the asynchronous work into the connection's async_requests list via setup_async_work(). The cancel callback smb2_remove_blocked_lock() holds a reference to the flock.
If the lock waiter is subsequently woken up but the work state is no longer KSMBD_WORK_ACTIVE (e.g., due to a concurrent cancellation), the cleanup path calls locks_free_lock(flock) without dequeuing the work from the async_requests list. Concurrently, smb2_cancel() walks the list under conn->request_lock and invokes the cancel callback, which then dereferences the already freed 'flock'. This leads to a slab-use-after-free inside __wake_up_common.
Fix this by restructuring the cleanup logic after the worker returns from ksmbd_vfs_posix_lock_wait(). Move list_del(&smb_lock->llist) and release_async_work(work) to the top of the cleanup block. This guarantees that the async work is completely dequeued and serialized under conn->request_lock before locks_free_lock(flock) is called, rendering the flock unreachable for any concurrent smb2_cancel().
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 07/26/2026
This vulnerability exists within the ksmbd kernel module responsible for SMB2 protocol implementation in Linux systems. The flaw manifests as a use-after-free condition that occurs during deferred byte-range lock cancellation processes. When a blocking byte-range lock request is deferred through the FILE_LOCK_DEFERRED path, the system registers asynchronous work into the connection's async_requests list using setup_async_work() function. The problematic scenario emerges when the lock waiter is awakened but the work state has transitioned from KSMBD_WORK_ACTIVE to another state due to concurrent cancellation operations.
The technical implementation issue stems from improper synchronization between the cleanup path and concurrent cancellation operations. During normal execution flow, when ksmbd_vfs_posix_lock_wait() returns, the cleanup logic executes but fails to properly sequence the removal of work items from the async_requests list before calling locks_free_lock(flock). This creates a race condition where smb2_cancel() can still access the freed memory structure while walking through conn->request_lock. The specific memory corruption occurs within the __wake_up_common kernel function when the cancel callback attempts to dereference the already freed 'flock' structure, resulting in slab-use-after-free behavior.
The operational impact of this vulnerability is significant as it represents a potential privilege escalation vector that could allow malicious actors to execute arbitrary code within kernel space. The flaw affects systems running Linux kernels with ksmbd support, particularly those handling SMB2 protocol connections with concurrent locking operations. Attackers could exploit this through carefully crafted SMB2_LOCK requests that trigger the specific race condition during deferred lock cancellation, potentially leading to system compromise.
The vulnerability aligns with CWE-416 Use After Free, which specifically addresses improper handling of freed memory references in kernel space. From an ATT&CK perspective, this represents a privilege escalation technique (T1068) through kernel exploitation, potentially enabling attackers to gain elevated privileges and execute malicious code with kernel-level permissions. The fix implements proper synchronization by restructuring the cleanup logic to ensure list_del(&smb_lock->llist) and release_async_work(work) operations occur before locks_free_lock(flock) is invoked. This ensures complete dequeuing and serialization under conn->request_lock protection, preventing concurrent access to freed memory structures during the cancellation process.
The mitigation strategy requires updating to kernel versions containing the patched ksmbd implementation where the cleanup sequence has been restructured to maintain proper ordering of operations. System administrators should prioritize applying security patches that address this specific kernel module vulnerability while monitoring for potential exploitation attempts targeting SMB2 protocol implementations. The fix demonstrates proper resource management practices by ensuring memory deallocation occurs only after all references are removed from concurrent access lists, preventing the classic use-after-free scenario that could lead to arbitrary code execution in kernel space.