CVE-2026-64385

What it actually does

This is a Linux kernel SMB client memory-corruption flaw in the SMB2_ioctl() replay path. Under specific error-retry conditions, the client can free a response buffer, retain stale response bookkeeping, and then free the same buffer again if SMB2_ioctl_init() fails before the next send. Because the bug occurs in kernel memory, successful exploitation could crash the system or potentially enable code execution with kernel privileges, depending on allocator state, hardening, kernel configuration, and exploit reliability.

Why it matters to the business

Systems that mount or access SMB/CIFS shares from untrusted, compromised, or attacker-controlled servers may be exposed to kernel-level compromise or denial of service. Operationally, this can mean server crashes, service outages, corrupted workloads, or a foothold that bypasses normal user-space controls. Although the EPSS score is currently low, the CVSS severity is critical and the flaw is only 16 days old, so organizations with Linux hosts using SMB client functionality should prioritize inventory and patch planning before public exploit techniques mature.

How an attack unfolds

An attacker needs a path to interact with a vulnerable Linux SMB client, most plausibly by operating a malicious SMB server, compromising a legitimate SMB server, spoofing or intercepting SMB traffic where network positioning allows, or inducing a target system to mount or access an attacker-controlled SMB share. The attacker returns crafted SMB2 ioctl responses and replayable error conditions that drive the client through the vulnerable retry path. After one attempt frees a response buffer, a later failure in SMB2_ioctl_init() causes cleanup code to free the stale buffer again. This double-free corrupts kernel heap state and may lead to a kernel panic or, with a reliable exploit chain, arbitrary kernel memory manipulation and privileged code execution.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the SMB client double-free in SMB2_ioctl() replay handling. No exact fixed package versions were provided, so track the relevant vendor kernel advisories for each distribution and update to the vendor-fixed kernel build when available. Reboot systems after kernel updates to ensure the patched kernel is running. If immediate patching is not possible, reduce exposure by disabling unnecessary CIFS/SMB client mounts, blocking outbound SMB connections to untrusted networks, restricting SMB mounts to known trusted servers, enforcing SMB signing where applicable, and avoiding automatic mounting of user-supplied or internet-accessible SMB shares. These mitigations reduce attack surface but do not replace patching.

How to confirm the fix worked

Confirm exposure by identifying Linux systems with the CIFS/SMB client module loaded or configured SMB mounts, such as entries using cifs in mount output, /proc/mounts, /etc/fstab, or automount configuration. Validate remediation by confirming the host has booted into a vendor kernel version that contains the SMB client fix, not merely that the package was installed. Check uname -r, package manager kernel versions, and vendor security advisory mappings. After patching and rebooting, verify SMB mounts still function and review kernel logs for absence of SMB2_ioctl, CIFS, double-free, slab, or kernel oops messages during SMB activity.

Typical attack path

1. Identify Linux systems that use the kernel CIFS/SMB client to mount SMB shares or access SMB resources.
2. Gain control of an SMB server the target connects to, position as a malicious SMB endpoint, or intercept SMB traffic where feasible.
3. Trigger SMB2 ioctl operations that produce a response-bearing attempt followed by a replayable error.
4. Cause the next SMB2_ioctl_init() operation to fail before the next send while stale response bookkeeping remains present.
5. Trigger cleanup that frees the previously freed response buffer a second time.
6. Leverage the resulting kernel heap corruption to crash the host or attempt kernel-level code execution.

How to detect it

Look for evidence that vulnerable Linux hosts connected to suspicious SMB servers shortly before kernel instability, crashes, or reboots. Useful sources include kernel logs, system journal, crash dumps, kdump/vmcore artifacts, EDR kernel panic telemetry, network flow logs, firewall/proxy logs for outbound SMB, authentication logs for SMB mount activity, and configuration sources such as /etc/fstab and automount maps. Investigate kernel messages mentioning CIFS, SMB2_ioctl(), SMB2_ioctl_init(), double free, slab corruption, general protection faults, BUG/Oops, or panic events near SMB activity. Correlate with outbound connections to TCP/445 or TCP/139, especially to new, external, user-controlled, or unusual SMB servers. Because exploit maturity is currently listed as none and there are no named threat actors or known KEV exploitation entries, detections should focus on behavioral evidence of attempted triggering and post-crash forensics rather than known attacker signatures.

• SMB2_ioctl
• SMB2_ioctl_init
• CIFS: VFS
• cifs.ko
• mount.cifs
• type cifs
• kernel: BUG:
• kernel: Oops:
• kernel panic
• double free
• slab corruption
• general protection fault
• KASAN: double-free
• KASAN: use-after-free
• TCP/445
• TCP/139
• /proc/fs/cifs/DebugData
• /etc/fstab
• /proc/mounts

What your security team should do

• Prioritize patching Linux systems that mount SMB/CIFS shares, especially servers, backup systems, file-processing hosts, VDI infrastructure, and systems connecting to third-party or user-controlled SMB shares.
• Inventory outbound SMB usage by reviewing mounted CIFS shares, automount rules, endpoint telemetry, and network flows to TCP ports 445 and 139.
• Restrict outbound SMB to approved file servers using host firewalls, network ACLs, or egress filtering; block SMB to the internet and untrusted segments.
• Monitor kernel logs and EDR telemetry for CIFS/SMB client crashes, kernel oops events, allocator corruption, or unexpected reboots following SMB activity.
• Treat unexplained kernel crashes on SMB client systems as potentially security-relevant until patched and investigated.
• Where feasible, require SMB signing and avoid mounting SMB shares from unauthenticated or user-supplied locations.
• Track vendor advisories for exact fixed kernel versions and ensure systems are rebooted into the patched kernel after updates.