CVE-2026-64383

What it actually does

This is a Linux kernel SMB/CIFS client memory-corruption flaw in the SMB2_flush() replay path. During a replayable SMB2 flush operation, response-buffer state can be reused across retry attempts; if a retry fails before a replacement response buffer is stored, cleanup can free the stale response pointer a second time. A malicious or compromised SMB server, or an attacker able to intercept and manipulate SMB traffic, may be able to trigger a kernel double-free in the client. The practical outcome is most likely a kernel crash or denial of service, but because the bug occurs in kernel memory management, exploitation could potentially lead to arbitrary kernel memory corruption and code execution depending on allocator state, kernel hardening, and exploit reliability.

Why it matters to the business

Systems that mount SMB/CIFS shares from untrusted, compromised, or attacker-controlled servers could be crashed or potentially taken over at the kernel level. This can interrupt file access, application workloads, desktops, servers, and appliances that depend on network shares. Although the issue is not currently in CISA KEV, has no known public exploit maturity in the supplied data, and has a low EPSS score, the CVSS impact is high because successful exploitation occurs in kernel context and can affect confidentiality, integrity, and availability.

How an attack unfolds

An attacker first needs a victim Linux system to initiate or maintain an SMB/CIFS client connection to an SMB server the attacker controls or can manipulate in transit. The attacker then causes the client to issue an SMB2 flush request, for example during file write or synchronization activity. The malicious SMB endpoint returns conditions that make the flush response replayable, then causes the following retry path to fail before cifs_send_recv() replaces the response buffer bookkeeping. Because SMB2_flush() retained stale response-buffer state across replay attempts, the error cleanup path can free the same response buffer a second time. Triggering the double-free may crash the kernel immediately, or with careful heap shaping may allow broader kernel memory corruption. Exploitation reliability depends heavily on the running kernel build, allocator configuration, hardening features such as KASAN/KFENCE/SLUB freelist protections, and the attacker’s ability to influence SMB client behavior.

How to fix it

Upgrade to a Linux kernel version or vendor kernel package that includes the fix for the SMB client SMB2_flush() replay double-free. Because no exact fixed versions were provided in the input, use the fixed kernel advisory from the relevant distribution or kernel supplier and confirm that the patch reinitializes resp_buftype and rsp_iov at the top of the SMB2_flush() replay loop. Where immediate patching is not possible, reduce exposure by disabling unnecessary CIFS/SMB client mounts, preventing automatic mounts from untrusted locations, restricting outbound SMB traffic to approved file servers only, blocking TCP/445 and TCP/139 to untrusted networks, using VPN or trusted network paths for SMB, and avoiding connections to third-party or internet-accessible SMB servers. Kernel hardening and memory-corruption mitigations may reduce exploitability but should not be treated as a substitute for patching.

How to confirm the fix worked

Confirm the running kernel package has been updated to a vendor build containing the SMB2_flush() replay fix, then reboot if required so the patched kernel is active. Validate with uname -a, package-manager query output, and vendor advisory metadata rather than only checking that a package was downloaded. If source validation is possible, confirm the SMB client code reinitializes resp_buftype and rsp_iov at the beginning of each SMB2_flush() replay-loop iteration. Review current SMB/CIFS mounts with mount, findmnt, /proc/mounts, and autofs/systemd mount units to ensure only trusted SMB servers are used. Confirm network controls block outbound SMB to unauthorized destinations. After patching, monitor dmesg and journal logs during representative SMB write/flush workloads to ensure there are no CIFS-related kernel oops, slab double-free, or memory-corruption messages.

Typical attack path

1. Identify Linux systems that mount SMB/CIFS shares or can be induced to connect to an attacker-controlled SMB server.
2. Position a malicious SMB server or gain the ability to tamper with SMB traffic between the client and server.
3. Trigger file activity that causes the Linux SMB client to issue SMB2 flush operations.
4. Return a replayable SMB2 flush response and manipulate the retry sequence so the next attempt fails before a new response buffer is recorded.
5. Cause SMB2_flush() cleanup to act on stale response state and free the same buffer twice.
6. Leverage the resulting kernel memory corruption for denial of service, and potentially attempt privilege escalation or kernel-level code execution if exploit primitives are reliable.

How to detect it

To assess whether this was already exploited, review kernel logs, system journals, crash dumps, and endpoint telemetry for memory-corruption or kernel-oops events that occurred while the host was using SMB/CIFS mounts. Relevant log sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, /var/crash, kdump/vmcore repositories, apport/ABRT crash records, EDR kernel-event telemetry, and network flow logs showing outbound SMB connections. Correlate crashes or reboots with SMB client activity, especially connections to new, external, or unexpected SMB servers over TCP/445 or TCP/139. Look for stack traces referencing SMB2_flush(), cifs_send_recv(), CIFS VFS, SMB2, slab allocator errors, double-free detection, KASAN reports, KFENCE reports, or general protection faults in kernel context. Because exploitation may only leave a crash artifact and not a stable file-based implant, absence of conventional malware indicators does not rule out attempted exploitation. If kernel code execution is suspected, perform memory forensics and compare loaded modules, kernel text integrity, persistence mechanisms, and credential access artifacts against known-good baselines.

• SMB2_flush
• cifs_send_recv
• CIFS: VFS:
• BUG: KASAN: double-free
• KASAN: double-free
• double free or corruption
• kernel BUG at mm/slub.c
• kernel BUG at mm/page_alloc.c
• general protection fault
• BUG: unable to handle kernel NULL pointer dereference
• RIP: 0010:SMB2_flush
• RIP: 0010:cifs_send_recv
• kfence: invalid free
• slub: Object already free
• TCP/445
• TCP/139
• /proc/fs/cifs/Stats
• /proc/fs/cifs/DebugData
• /var/log/kern.log
• /var/log/messages
• /var/crash
• vmcore

What your security team should do

• Prioritize patching Linux systems that mount SMB/CIFS shares, especially servers, virtual desktop hosts, file-processing systems, and endpoints that connect to SMB servers outside tightly controlled networks.
• Inventory SMB/CIFS client usage across Linux fleets using mount data, configuration management, endpoint telemetry, and network flow logs for outbound TCP/445 and TCP/139.
• Restrict SMB client egress so Linux hosts can connect only to approved SMB file servers; block SMB to the internet and untrusted network segments.
• Investigate any recent kernel panic, unexplained reboot, or memory-corruption event involving CIFS, SMB2_flush, cifs_send_recv, or SMB2 client activity.
• Hunt for Linux hosts connecting to unusual SMB servers around the time of crashes or application file-write failures.
• Disable or remove unnecessary CIFS mounts, autofs entries, and user-driven SMB mounting workflows until patched.
• Treat confirmed exploitation as a kernel-level compromise risk: preserve forensic evidence, isolate affected hosts, rotate credentials exposed through SMB sessions, and rebuild if kernel code execution is suspected.