CVE-2026-64382

What it actually does

This is a Linux kernel SMB client memory-corruption flaw in the SMB2 open/replay path. A remote SMB server can cause a replayable error after a response buffer has already been freed; if the next SMB2 open initialization fails before retransmission, stale response bookkeeping can cause the same buffer to be freed again. Because this occurs in kernel context, successful exploitation can result in kernel memory corruption, system crash, or potentially arbitrary code execution with kernel privileges, although public exploit maturity is currently reported as none and EPSS is low.

Why it matters to the business

Systems that connect to untrusted or attacker-controlled SMB shares could be crashed or potentially compromised at the operating-system level. The most realistic operational risk is workstation or server instability after accessing a malicious SMB resource; the higher-impact scenario is full host compromise if the double-free is weaponized. The issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has low EPSS, but the CVSS severity is high because exploitation affects the kernel and can compromise confidentiality, integrity, and availability.

How an attack unfolds

An attacker must get a vulnerable Linux system to act as an SMB client and initiate a connection to a server the attacker controls or can manipulate, such as through a malicious file-share link, mounted share, or network redirection. The malicious SMB server returns SMB2 open responses and replayable errors in a sequence that causes the Linux client to free a response buffer. The attacker then influences the next replay attempt so that SMB2_open_init() fails before a new request is sent, leaving stale response bookkeeping in place. Cleanup logic then frees the previous response buffer a second time. Depending on kernel configuration, heap state, hardening, and exploit reliability, this may produce a kernel panic or be shaped into kernel memory corruption with potential privilege escalation or remote code execution in the client kernel context.

How to fix it

Apply the Linux kernel update from the relevant distribution or kernel vendor that includes the SMB client fix for the SMB2_open() replay double-free. No exact fixed package versions were provided in the input, so remediation should be based on vendor advisories for the running distribution and kernel branch. Where immediate patching is not possible, reduce exposure by blocking outbound SMB traffic to untrusted networks, especially TCP/445 and TCP/139; disabling or unloading the CIFS/SMB client module where SMB mounts are not required; removing untrusted SMB automounts; restricting desktop file managers and services from browsing arbitrary SMB locations; and requiring access only to trusted, authenticated SMB servers. Reboot after kernel updates to ensure the fixed kernel is running.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, has been updated by checking the active kernel version after reboot and comparing it with the distribution advisory that contains the SMB client double-free fix. Verify whether the SMB/CIFS client is in use by checking loaded modules such as cifs and active mounts of type cifs. Validate compensating controls by confirming outbound TCP/445 and TCP/139 are blocked to untrusted destinations and that only approved SMB servers are reachable. For source-based validation, confirm the SMB client replay path resets response bookkeeping before each SMB2 open attempt so stale response buffer state cannot be reused during cleanup.

Typical attack path

1. Identify vulnerable Linux systems that use the in-kernel SMB/CIFS client to access SMB shares.
2. Host or compromise an SMB server reachable by the target over TCP/445 or TCP/139.
3. Induce a user, service, desktop file manager, automount job, backup job, or application to access the attacker-controlled SMB share.
4. Return crafted SMB2 open responses and replayable errors that exercise the SMB2_open() replay path.
5. Cause SMB2_open_init() to fail before the next send so stale response bookkeeping remains active.
6. Trigger cleanup that frees the same response buffer twice.
7. Leverage the resulting kernel memory corruption to crash the host or attempt code execution in kernel context.

How to detect it

There are no definitive network or file-based indicators unique to this vulnerability from the provided information, so detection should focus on evidence of vulnerable SMB client activity followed by kernel memory-corruption symptoms. Review Linux kernel logs from journald, dmesg, /var/log/kern.log, /var/log/messages, and crash collection systems for double-free, slab corruption, KASAN, kernel oops, or panic events referencing the CIFS/SMB client or SMB2 open activity. Correlate those events with outbound SMB connections, especially TCP/445 or TCP/139 to newly observed, external, or untrusted servers. Review process execution and audit logs for mount.cifs, systemd mount units, autofs, gvfsd-smb, file-manager SMB browsing, backup agents, or scripts that initiated SMB access shortly before a crash. In network telemetry, look for Linux clients initiating SMB2 sessions to unusual servers immediately before disconnects, resets, or host unavailability. Because exploitation may only leave a crash artifact, absence of persistent files or processes does not rule out attempted exploitation.

• BUG: KASAN: double-free
• KASAN: double-free
• double free
• kernel BUG
• kernel oops
• general protection fault
• slab corruption
• CIFS: VFS
• SMB2_open
• mount.cifs
• gvfsd-smb
• TCP/445
• TCP/139
• cifs.ko

What your security team should do

• Prioritize patching Linux systems that mount SMB/CIFS shares, browse network shares, run backup jobs to SMB destinations, or operate in environments where users can access arbitrary SMB links.
• Inventory active CIFS/SMB mounts and systems with the cifs kernel module loaded to identify exposed hosts.
• Restrict outbound SMB traffic to approved internal file servers; block SMB egress to the internet and untrusted network segments.
• Review automount configurations, desktop file manager integrations, backup software, and scripts that may automatically connect to SMB shares.
• Monitor for kernel crashes, KASAN double-free reports, CIFS/SMB2 open errors, and outbound SMB connections to unusual destinations.
• Because there is no known KEV listing, ransomware association, or public exploit maturity at this time, treat this as high-severity patching rather than emergency exploitation response unless local telemetry shows suspicious SMB-triggered crashes.