CVE-2026-64396

What it actually does

This vulnerability is a use-after-free in the Linux kernel ksmbd SMB server implementation during cancellation of deferred SMB2 byte-range lock requests. An authenticated SMB client can trigger a race between a deferred lock waiter cleanup path and SMB2 cancellation handling, causing ksmbd to dereference a freed struct file_lock. Because this occurs in kernel context, successful exploitation can cause kernel memory corruption with high-impact outcomes including denial of service through kernel panic and, depending on kernel configuration, allocator state, and exploit reliability, potential privilege escalation or arbitrary kernel code execution.

Why it matters to the business

Systems using the in-kernel Linux SMB server, ksmbd, may be exposed to remote authenticated attacks that can crash file-sharing servers or potentially compromise the underlying host. Business impact can include interruption of file shares, data access disruption, loss of integrity or confidentiality of files hosted by the server, and emergency maintenance windows for kernel patching. Although this issue is not currently listed in CISA KEV and has low EPSS at the time of assessment, the CVSS severity is high and SMB services are commonly reachable inside enterprise networks, making timely remediation important for Linux file servers that enable ksmbd.

How an attack unfolds

An attacker first obtains valid SMB credentials or access to an account permitted to connect to a ksmbd-backed SMB share. The attacker then establishes an SMB session and issues byte-range lock operations designed to enter the deferred blocking lock path. While a lock request is pending, the attacker sends cancellation activity, such as SMB2 cancel requests, timed to race with the server-side wake-up and cleanup of the deferred lock. In the vulnerable kernel code, cleanup may free the file_lock object while the associated async work remains reachable from the connection's async_requests list. A concurrent cancellation path can then walk that list and invoke a callback that dereferences the already freed object, producing kernel use-after-free behavior. In the simplest case, this causes a kernel crash or ksmbd service disruption; with sufficient heap grooming and exploit development, the memory corruption may be abused for stronger compromise of the host.

How to fix it

Apply the Linux kernel update from the relevant distribution or kernel vendor that includes the ksmbd fix for deferred SMB2 lock cancellation cleanup. Because exact fixed package versions were not provided, track vendor advisories for the deployed kernel stream and confirm the patch restructures ksmbd cleanup so async work is dequeued and released before locks_free_lock(flock) is called. Where immediate patching is not possible, disable ksmbd if it is not required, migrate exposed SMB service to a patched implementation, restrict SMB access to trusted networks and authenticated users only, and block TCP/445 from untrusted segments. Do not rely solely on network restrictions for long-term mitigation, because the flaw is reachable by any authenticated SMB client that can interact with the vulnerable ksmbd service.

How to confirm the fix worked

Confirm exposure by checking whether the host is running a kernel version that includes ksmbd and whether the ksmbd service/module is loaded or active. Validate remediation by verifying the installed kernel package is at or above the vendor-fixed build and rebooting into the patched kernel. Confirm ksmbd is no longer vulnerable by reviewing the vendor changelog or kernel source for the cleanup change in the SMB2_LOCK deferred-lock cancellation path, specifically ensuring async work is removed from the connection async request list before the file_lock object is freed. Operationally, verify SMB shares remain functional after patching and monitor kernel logs for absence of KASAN, slab use-after-free, oops, panic, or ksmbd stack traces during SMB lock/cancel activity.

Typical attack path

1. Identify a Linux SMB server using the in-kernel ksmbd service rather than Samba userspace smbd.
2. Authenticate to the SMB service with valid credentials that permit access to a share.
3. Open a file over SMB and issue SMB2 byte-range lock requests that can block and enter the deferred lock path.
4. Trigger cancellation of the pending SMB2 lock request while the server is concurrently waking or cleaning up the deferred lock waiter.
5. Win the race so the async cancellation callback references a freed struct file_lock.
6. Cause kernel memory corruption, commonly resulting in a denial of service and potentially enabling further kernel-level exploitation depending on platform hardening.

How to detect it

Look for evidence of both exploitation attempts and resulting kernel memory corruption. Primary log sources include kernel logs from journald or syslog, distribution crash collectors, audit logs, SMB authentication logs, firewall or flow logs for TCP/445, and any available endpoint telemetry. Search for kernel oops, panic, KASAN, UBSAN, or slab allocator messages referencing ksmbd, SMB2_LOCK, smb2_cancel, smb2_remove_blocked_lock, ksmbd_vfs_posix_lock_wait, locks_free_lock, file_lock, or __wake_up_common. Correlate these events with authenticated SMB sessions from the same source shortly before the crash or oops. Suspicious patterns include repeated SMB connections that authenticate successfully, perform file open and locking operations, then disconnect or issue cancel operations shortly before ksmbd errors or host instability. Because public exploit maturity is currently reported as none and there are no named threat actors for this CVE in the provided data, absence of known malware indicators should not be treated as absence of exploitation; focus on behavioral and kernel-crash artifacts.

• KASAN: use-after-free
• BUG: KASAN: slab-use-after-free
• slab-use-after-free
• use-after-free in __wake_up_common
• __wake_up_common
• ksmbd
• smb2_cancel
• smb2_remove_blocked_lock
• ksmbd_vfs_posix_lock_wait
• locks_free_lock
• struct file_lock
• SMB2_LOCK
• FILE_LOCK_DEFERRED
• KSMBD_WORK_ACTIVE
• async_requests
• kernel BUG at
• Oops:
• Kernel panic - not syncing
• TCP/445

What your security team should do

• Inventory Linux systems exposing SMB on TCP/445 and determine which use ksmbd.
• Prioritize patching internet-facing, cross-segment, or broadly reachable internal ksmbd file servers.
• Apply the vendor-fixed kernel and reboot to ensure the patched kernel is running.
• If patching is delayed, disable ksmbd or restrict SMB access to trusted administrative and application subnets only.
• Review SMB authentication logs for unusual authenticated sessions followed by lock/cancel-heavy behavior or kernel instability.
• Enable and centralize kernel, audit, and service logs from Linux file servers to support post-incident investigation.
• Treat unexplained kernel crashes on ksmbd servers as potentially security-relevant until logs and memory evidence are reviewed.