CVE-2026-64397

What it actually does

This flaw is a concurrency-related stack use-after-free in the Linux kernel ksmbd SMB server implementation. When multiple SMB2 QUERY_DIRECTORY requests are issued concurrently against the same open directory handle, ksmbd can overwrite a shared readdir_data pointer while another directory enumeration callback is still using stack-allocated state. Because the bug occurs in kernel context and is reachable over the network, successful exploitation can potentially cause kernel memory corruption, system crash, information disclosure, or, in a worst case, kernel-level code execution.

Why it matters to the business

Systems exposing the in-kernel Linux SMB server could be remotely destabilized or compromised, potentially interrupting file sharing services, corrupting or exposing shared data, or giving an attacker deep control over the host. Although there is no known KEV listing or reported ransomware use and EPSS is currently low, the CVSS severity is critical because exploitation requires network access and no user interaction.

How an attack unfolds

An attacker first identifies a Linux host running ksmbd and reachable over SMB. They connect to the SMB service, open a directory, and reuse the same file handle while sending carefully timed concurrent SMB2 QUERY_DIRECTORY requests. The race condition causes one request to replace the per-file directory enumeration private pointer while another request is still processing callbacks that reference the previous stack-allocated data. This can trigger a stack use-after-free in kernel space. Depending on kernel configuration, allocator behavior, timing, and mitigations, the attacker may be able to cause a denial of service through a kernel panic or attempt more advanced memory-corruption exploitation to leak data or execute code with kernel privileges.

How to fix it

Apply the vendor kernel update that includes the ksmbd fix serializing QUERY_DIRECTORY handling per file with a per-file mutex. Where distribution-specific package versions are available, upgrade to the fixed kernel package from the operating system vendor rather than relying only on upstream source references. Reboot into the patched kernel after installation and confirm the running kernel version changed. If immediate patching is not possible, disable ksmbd, unload or prevent loading of the ksmbd module if feasible, block inbound SMB exposure from untrusted networks, restrict TCP/445 access to trusted clients, and prefer a patched userspace SMB server if file sharing must remain available.

How to confirm the fix worked

Confirm whether ksmbd is enabled and listening for SMB traffic, then verify the host is running a kernel build that contains the fix for serialized per-file QUERY_DIRECTORY handling. Check the active kernel version after reboot, not just the installed package version. Validate that TCP/445 is not reachable from untrusted networks unless required. If ksmbd was disabled as a mitigation, confirm the ksmbd module is not loaded and the SMB service is not accepting connections. Kernel crash testing should only be performed in an isolated lab because proof-of-concept race triggering may panic the system.

Typical attack path

1. Scan for hosts exposing SMB services backed by Linux ksmbd.
2. Establish an SMB session to the target service.
3. Open a directory and obtain a reusable file handle.
4. Send concurrent SMB2 QUERY_DIRECTORY requests against the same file handle to create a race condition.
5. Trigger use of stale stack-backed directory enumeration state inside the kernel.
6. Cause a kernel crash or attempt to shape memory corruption for further compromise.

How to detect it

Look for evidence of exploitation in kernel logs, system journals, crash dumps, and network telemetry around SMB activity. Useful log sources include journalctl/kern.log/dmesg, distribution crash dump facilities such as kdump or apport, EDR kernel event telemetry, firewall logs, IDS/NSM records for TCP/445, and SMB server access logs if available. Suspicious patterns include kernel oops or panic events mentioning ksmbd, smb2_query_dir, iterate_dir, readdir, use-after-free, KASAN, or general protection faults shortly after bursts of SMB2 QUERY_DIRECTORY requests. Network telemetry may show a client repeatedly opening a directory and issuing many concurrent SMB2 QUERY_DIRECTORY operations against the same SMB session or file identifier. Because there are no public reports of exploitation in the provided data, treat these as behavioral and forensic indicators rather than confirmed attacker-specific IOCs.

• BUG: KASAN: stack-use-after-free
• stack-use-after-free
• smb2_query_dir
• ksmbd
• iterate_dir
• readdir_data
• QUERY_DIRECTORY
• SMB2 QUERY_DIRECTORY
• general protection fault
• kernel BUG at
• Oops:
• Kernel panic
• TCP/445

What your security team should do

• Prioritize patching Linux systems that expose ksmbd over TCP/445, especially internet-facing or broadly reachable file servers.
• Inventory hosts using the in-kernel ksmbd service and distinguish them from systems using Samba/smbd, which is a different implementation.
• Restrict SMB access to trusted network segments and block inbound TCP/445 from the internet wherever possible.
• Monitor kernel logs for use-after-free, KASAN, oops, panic, or ksmbd-related crash artifacts until patching is complete.
• If patching is delayed, disable ksmbd or remove the module where operationally feasible.
• Review file server availability incidents around the publication window and after for unexplained kernel crashes or reboots associated with SMB traffic.