CVE-2026-64437

What it actually does

This is a use-after-free vulnerability in the Linux kernel ksmbd SMB server. An authenticated SMB client can cause a deferred file lock object to be freed when an SMB2_CLOSE changes pending lock work into a terminal CLOSED state, while the associated async work remains reachable on the connection's async request list with a cancellation callback still pointing to the freed file_lock. A later SMB2_CANCEL for the same AsyncId can invoke that callback again and operate on freed kernel memory. The most likely immediate impact is a kernel crash or denial of service; depending on allocator state, kernel hardening, and exploit development, use-after-free bugs in kernel context may also be abused for privilege escalation or remote code execution in the kernel from the network-accessible SMB service. Exploitation requires network access to ksmbd and valid SMB authentication, but no user interaction.

Why it matters to the business

Systems using the in-kernel Linux SMB server may be exposed to authenticated attackers who can disrupt file-sharing services or potentially compromise the host at the kernel level. Because SMB servers often support shared storage, backups, home directories, application data, or cross-platform file exchange, exploitation could interrupt business operations, corrupt active workflows, or become a foothold for broader compromise. The issue is not currently listed in CISA KEV, has low EPSS at the time of assessment, and no public exploit maturity was provided, but the CVSS severity is high and SMB services are commonly reachable inside enterprise networks, so internet-exposed or broadly accessible ksmbd deployments should be prioritized.

How an attack unfolds

An attacker first obtains valid SMB credentials for a system running the Linux kernel ksmbd server. The attacker opens a file over SMB and creates a blocking or deferred byte-range lock operation that leaves asynchronous lock work pending on the connection. The attacker then sends an SMB2_CLOSE on the locking handle, causing the kernel worker to transition the deferred work to a CLOSED state and free the associated file_lock during the non-active early-exit path, while leaving the async request entry and its cancel callback available. The attacker then sends an SMB2_CANCEL for the same AsyncId. Because the vulnerable logic only skipped work already marked CANCELLED and did not also skip CLOSED work, ksmbd invokes the cancellation callback against the freed file_lock, triggering use-after-free in kernel lock handling. A reliable attack would attempt to shape kernel heap state around this sequence to convert the memory-safety error into a crash or, in a more advanced scenario, controlled kernel memory corruption.

How to fix it

Apply a Linux kernel update that contains the upstream ksmbd fix for this issue. If using distribution kernels, install the vendor-published kernel package that backports the patch; fixed package versions were not provided in the input, so rely on the distribution security advisory and changelog for confirmation. Reboot into the fixed kernel after updating. Where immediate patching is not possible, reduce exposure by disabling ksmbd if it is not required, unloading or preventing use of the ksmbd module where feasible, replacing it temporarily with a patched userspace SMB implementation if appropriate, restricting TCP/445 access to trusted management and client networks, blocking internet exposure, and enforcing strong SMB authentication. Also review whether CONFIG_SMB_SERVER is enabled and whether the ksmbd service is actively running, because systems not using ksmbd are not exposed through this code path.

How to confirm the fix worked

Confirm exposure by checking whether the running kernel includes ksmbd support and whether the ksmbd service/module is active. Useful checks include reviewing kernel configuration for CONFIG_SMB_SERVER, checking loaded modules for ksmbd, inspecting active listeners on TCP/445, and confirming whether shares are served by ksmbd rather than another SMB implementation. Confirm remediation by verifying the running kernel version after reboot, checking distribution advisory metadata or kernel changelogs for the ksmbd fix, and ensuring the patched kernel is the one currently booted. If mitigation rather than patching is used, validate that ksmbd is stopped or unavailable, TCP/445 is restricted by firewall policy, and unauthenticated or untrusted network segments cannot reach the SMB service. In test environments, kernel sanitizers or crash logs should no longer show use-after-free traces involving smb2_cancel, smb2_remove_blocked_lock, locks_delete_block, or file_lock_cache when exercising SMB2 lock, close, and cancel behavior.

Typical attack path

1. Identify a Linux host exposing SMB through the in-kernel ksmbd service, typically on TCP port 445.
2. Authenticate to the SMB service using valid credentials.
3. Open a file and issue an SMB2 lock request that results in deferred asynchronous lock work.
4. Send SMB2_CLOSE on the locking handle so the pending lock work enters the CLOSED terminal state and frees its file_lock object without fully releasing the async work.
5. Send SMB2_CANCEL for the same AsyncId associated with the deferred lock request.
6. Trigger the stale cancellation callback, causing ksmbd to operate on freed kernel memory.
7. Use the resulting kernel memory corruption to crash the host or attempt more advanced exploitation if heap control is achievable.

How to detect it

Look for signs of kernel memory corruption or crashes on Linux SMB servers running ksmbd. Primary log sources are kernel logs, system journal, crash dumps, kdump/vmcore artifacts, distribution crash reporting, endpoint telemetry, and network security logs for SMB traffic. In kernel logs, search for KASAN or general protection fault traces containing ksmbd functions in the SMB2 cancel and lock cleanup path, especially smb2_cancel, smb2_remove_blocked_lock, ksmbd_vfs_posix_lock_unblock, locks_delete_block, __locks_delete_block, locks_free_lock, and file_lock_cache. In SMB/network telemetry, look for authenticated sessions that perform unusual combinations of SMB2 LOCK, SMB2 CLOSE, and SMB2 CANCEL operations against the same session/tree/file context, especially repeated CANCEL messages referencing pending asynchronous operations or followed by server crashes, dropped SMB sessions, reboot events, or kernel oops messages. If packet capture is available, correlate SMB2_CANCEL requests with prior asynchronous lock operations and handle closes. Also review authentication logs for the SMB account and source IP active immediately before the crash. Absence of these artifacts does not prove non-exploitation, because a non-instrumented production kernel may only show a generic oops, service reset, or reboot rather than a detailed KASAN report.

• BUG: KASAN: slab-use-after-free in __locks_delete_block
• slab-use-after-free in __locks_delete_block
• __locks_delete_block
• locks_delete_block
• ksmbd_vfs_posix_lock_unblock
• smb2_remove_blocked_lock
• smb2_cancel
• handle_ksmbd_work
• locks_free_lock
• locks_alloc_lock
• file_lock_cache
• ksmbd:
• KASAN: slab-use-after-free
• general protection fault
• kernel BUG
• Oops:
• TCP/445
• SMB2_CANCEL
• SMB2_CLOSE
• SMB2 LOCK

What your security team should do

• Inventory Linux systems exposing SMB and identify which ones use the in-kernel ksmbd server.
• Prioritize patching or mitigation for ksmbd hosts reachable from untrusted networks, shared user networks, VPN address ranges, or any environment where many users have SMB credentials.
• Install the vendor-provided fixed kernel and reboot; verify the running kernel, not just the installed package, is fixed.
• Disable ksmbd on systems where in-kernel SMB serving is not required.
• Restrict TCP/445 to authorized client subnets and block internet exposure.
• Monitor kernel logs for crashes or KASAN-style use-after-free reports involving ksmbd, smb2_cancel, smb2_remove_blocked_lock, and file_lock_cache.
• Review SMB authentication logs for unusual authenticated clients repeatedly issuing lock, close, and cancel sequences or causing connection resets and kernel faults.
• Treat any confirmed kernel use-after-free crash on an SMB server as a potential compromise event until triaged, because kernel memory-corruption bugs can have impacts beyond denial of service.