CVE-2026-64390

What it actually does

This is a use-after-free flaw in the Linux kernel ksmbd SMB server implementation. When SMB3 multichannel is used, a byte-range lock may be created by one SMB connection and later removed by a different connection path, such as final close, durable handle preservation, unlock, or rollback. Because the lock entry can be removed while holding the wrong connection-specific spinlock, another thread traversing the original connection's lock list can access freed ksmbd_lock or file_lock structures. A remote authenticated SMB user could potentially trigger kernel memory corruption, leading to denial of service through a kernel crash and, depending on exploitability on a given kernel build and hardening configuration, possible kernel-level code execution or privilege escalation.

Why it matters to the business

Systems that expose Linux ksmbd file sharing may be vulnerable to remote authenticated attacks that can crash the file server or potentially compromise the underlying host. The most immediate operational risk is disruption of SMB file access, which can affect shared drives, application file workflows, backup paths, and user productivity. Because the issue is in kernel code, successful exploitation has high impact even though exploitation currently appears immature, is not listed in CISA KEV, and has a low EPSS score. Organizations using ksmbd rather than Samba should still prioritize remediation on internet-facing, partner-facing, or broadly accessible internal SMB servers.

How an attack unfolds

An attacker first obtains valid SMB credentials or otherwise gains the ability to authenticate to a vulnerable ksmbd service. They connect to the server using SMB3 and exercise multichannel behavior so that different SMB connections can interact with the same opened file state. The attacker issues SMB2_LOCK requests to create byte-range locks, then triggers close, unlock, durable handle, rollback, or reconnect paths in a timing-dependent way so lock entries are removed under a connection lock that does not own the list being modified. By racing lock-list traversal against removal and free operations, the attacker can cause the kernel to dereference freed ksmbd_lock or file_lock memory. The most likely observable outcome is a kernel warning, oops, panic, ksmbd worker crash, or SMB service disruption; a more advanced exploit could attempt to shape freed kernel memory to gain control over execution.

How to fix it

Upgrade the Linux kernel to a version that includes the ksmbd fix for tracking the connection that owns each byte-range lock list entry. If exact vendor package versions are not known, apply the latest security kernel updates from the operating system vendor or distribution and reboot into the updated kernel. If immediate patching is not possible, disable ksmbd where feasible, replace kernel SMB serving with a patched user-space Samba deployment if operationally appropriate, or restrict SMB access to trusted networks and users only. Reduce exposure by blocking TCP/445 from untrusted networks, disabling SMB3 multichannel if a supported mitigation exists for the deployed kernel/vendor build, and limiting write/lock-capable access to sensitive shares. Kernel live patching may not be sufficient unless the vendor explicitly confirms this flaw is covered; plan for a reboot after kernel update.

How to confirm the fix worked

Confirm whether the system uses ksmbd, not only Samba, by checking for loaded ksmbd kernel modules, ksmbd processes, kernel configuration, and active listeners on TCP/445. Validate remediation by confirming the running kernel version is at or above the vendor-fixed build and that the host has been rebooted into the updated kernel. Review vendor advisories or kernel changelogs for the ksmbd byte-range lock ownership fix. Confirm SMB exposure is limited to intended interfaces and networks. Where safe in a test environment, run SMB regression tests covering SMB3 multichannel, byte-range locking, file close, durable handles, and reconnect behavior to ensure stability after patching. Do not attempt race-condition proof-of-concept testing on production file servers because failed attempts may crash the kernel.

Typical attack path

1. Identify a host exposing SMB service backed by the Linux kernel ksmbd server.
2. Authenticate to the SMB service using a valid low-privileged account.
3. Negotiate SMB3 behavior and establish multiple channels or connections associated with the same session or file activity.
4. Open a file and issue SMB2_LOCK byte-range lock requests over one connection.
5. Trigger close, durable handle preservation/reconnect, unlock, or rollback behavior over another connection.
6. Race concurrent traversal of the connection lock list against removal of the byte-range lock entry.
7. Cause use-after-free access to ksmbd_lock or file_lock kernel objects, resulting in kernel crash, service disruption, or possible further memory-corruption exploitation.

How to detect it

Look for evidence of exploitation or attempted exploitation in kernel logs, system journals, SMB service logs, authentication logs, and network telemetry. Useful sources include journalctl/kern.log/dmesg, auditd, syslog, ksmbd logs if enabled, firewall or NetFlow records for TCP/445, and identity logs showing SMB logons. Investigate kernel oops, panic, KASAN, slab corruption, list corruption, or use-after-free messages involving ksmbd, ksmbd_lock, file_lock, SMB2_LOCK, durable handles, reconnect, or multichannel activity. Correlate crashes or ksmbd errors with authenticated SMB sessions that show repeated file opens, byte-range locks, disconnects, reconnects, durable handle operations, or multiple concurrent channels from the same client. Because exploitation may leave no durable file artifact and may only produce a crash, absence of logs does not prove absence of exploitation. Preserve kernel logs and crash dumps before rebooting or patching if compromise is suspected.

• ksmbd
• SMB2_LOCK
• ksmbd_lock
• file_lock
• BUG: KASAN: use-after-free
• use-after-free in ksmbd
• general protection fault
• kernel BUG at
• list_del corruption
• list_add corruption
• slab-use-after-free
• RIP: ksmbd
• Call Trace: ksmbd
• ksmbd:
• durable reconnect
• durable handle
• SMB3 multichannel
• TCP/445

What your security team should do

• Inventory Linux systems exposing SMB on TCP/445 and determine which ones use ksmbd.
• Prioritize patching ksmbd-enabled servers that are internet-facing, accessible from partner networks, or reachable by large internal user populations.
• Apply vendor kernel security updates and reboot into the fixed kernel as soon as practical.
• If patching is delayed, disable ksmbd or restrict SMB access using firewalls, VPN segmentation, and allowlists.
• Review SMB authentication logs for unusual authenticated access, repeated session setup, multichannel activity, file locking bursts, disconnect/reconnect loops, or crashes around SMB activity.
• Monitor kernel logs for use-after-free, KASAN, lock-list corruption, general protection faults, kernel oops, or panic messages involving ksmbd.
• Ensure SMB accounts follow least privilege and remove unnecessary write access to shares, since exploitation requires authenticated SMB interaction.
• Track vendor advisories for exact fixed kernel package versions and any backported patches for supported distributions.