CVE-2026-64396: ksmbd: fix UAF of struct file_lock in SMB2_LOCK deferred-lock cancellation
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix UAF of struct filelock in SMB2LOCK deferred-lock cancellation
When a blocking byte-range lock request is deferred in the FILELOCKDEFERRED path, ksmbd registers the asynchronous work into the connection's asyncrequests list via setupasyncwork(). The cancel callback smb2removeblockedlock() holds a reference to the flock.
If the lock waiter is subsequently woken up but the work state is no longer KSMBDWORKACTIVE (e.g., due to a concurrent cancellation), the cleanup path calls locksfreelock(flock) without dequeuing the work from the asyncrequests list. Concurrently, smb2cancel() walks the list under conn->requestlock and invokes the cancel callback, which then dereferences the already freed 'flock'. This leads to a slab-use-after-free inside wakeupcommon.
Fix this by restructuring the cleanup logic after the worker returns from ksmbdvfsposixlockwait(). Move listdel(&smblock->llist) and releaseasyncwork(work) to the top of the cleanup block. This guarantees that the async work is completely dequeued and serialized under conn->requestlock before locksfreelock(flock) is called, rendering the flock unreachable for any concurrent smb2cancel().
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Fix the UAF by moving list_del(&smb_lock->llist) and moving release_async_work(work) to the top of the cleanup block after the worker returns, ensuring the async work is completely dequeued/serialized under conn->async_requests list before locks_free_lock(flock) runs.
ksmbd (Linux kernel) smb2_remove_blocked_lock() deferred-lock cancellation cleanup logic = Restructure cleanup so the deferred async work is fully dequeued/serialized under conn->request_lock before locks_free_lock(flock) is called
Event History
Frequently Asked Questions
What access would an attacker need?
The CVSS vector indicates network reachability and low privileges are required, with no user interaction. Exploitation involves a blocking SMB2 byte-range lock request and a concurrent cancellation race.
Which systems are most relevant for triage?
Systems running the Linux kernel with ksmbd handling SMB2 requests are relevant, particularly where clients can issue blocking byte-range locks. The provided data does not state whether ksmbd is enabled by default.
What is the risk if the race is triggered?
The race can cause a slab use-after-free when cancellation code dereferences an already freed file-lock object. The supplied CVSS assessment rates confidentiality, integrity, and availability impact as high.
What does the fix need to ensure?
Before freeing the lock object, the deferred asynchronous work must be removed from the connection's async request list and released while serialized under the connection request lock. This prevents cancellation from reaching a callback that still references the freed lock.