CVE-2026-64381

What it actually does

This flaw is a memory leak in the Linux kernel SMB/CIFS client path for encrypted SMB traffic. When processing encrypted compound SMB protocol data units, the kernel allocates a follow-on buffer before enforcing the maximum compound-message limit. If the limit is exceeded, the function exits without attaching or freeing the allocated buffer, causing unreclaimed kernel memory. Repeated triggering can consume kernel memory and degrade or crash the affected system, making the primary impact denial of service rather than code execution or data theft.

Why it matters to the business

Systems that mount SMB shares from untrusted, compromised, or attacker-controlled SMB servers could experience memory exhaustion, service instability, application failures, or host reboots. The current public exploitation signal is low: EPSS is 0.00177, it is not listed in CISA KEV, it is not associated with ransomware use, and no mature public exploit is indicated. However, because the issue is in the Linux kernel and SMB clients are common in enterprise file-sharing workflows, organizations using Linux hosts to access SMB shares should remediate during normal kernel patch cycles, prioritizing systems that connect to third-party, internet-adjacent, or less-trusted SMB infrastructure.

How an attack unfolds

An attacker must be in a position to act as, compromise, or intercept traffic to an SMB server that a vulnerable Linux client connects to, with the relevant SMB encryption path in use. The attacker crafts encrypted SMB responses containing compound PDUs that exceed the kernel client's compound-message limit. Due to the vulnerable allocation order, the client allocates memory for the next buffer and then returns on the limit check without freeing it. By repeatedly causing the vulnerable client to process these malformed or excessive compound responses, the attacker can leak kernel memory over time. If repeated enough, the affected host may suffer memory pressure, degraded performance, failed workloads, out-of-memory events, or a reboot/panic depending on kernel configuration and workload pressure.

How to fix it

Apply the vendor kernel update that includes the upstream fix for the SMB client receive_encrypted_standard() buffer leak. Because no affected product list or package-specific fixed versions were provided, use the fixed kernel packages supplied by the relevant Linux distribution or appliance vendor rather than relying only on upstream source status. If immediate patching is not possible, reduce exposure by avoiding SMB mounts to untrusted servers, disabling or removing unnecessary CIFS/SMB client mounts, restricting outbound TCP/445 and TCP/139 to approved file servers, and isolating systems that must connect to less-trusted SMB shares. Where operationally feasible, avoid workflows that require Linux clients to connect to attacker-controlled or third-party SMB infrastructure until patched.

How to confirm the fix worked

Confirm that the running kernel package includes the SMB client fix, not merely that an updated package is installed. Validate with the distribution vendor advisory, kernel changelog, or package metadata for the applied kernel version, then reboot into the patched kernel if required. Inventory active SMB/CIFS mounts using standard host checks such as mount output, /proc/mounts, or findmnt for cifs file systems. Confirm network policy restricts outbound SMB to approved destinations. For higher-assurance validation in test environments, reproduce SMB client traffic against a controlled server and monitor kernel memory behavior before and after patching; patched systems should not show repeatable kernel memory growth when excessive encrypted compound SMB responses are rejected.

Typical attack path

1. Identify a Linux system that mounts SMB/CIFS shares using the vulnerable kernel SMB client code path.
2. Gain control of an SMB server the client connects to, impersonate one through network positioning, or induce the client to connect to an attacker-controlled SMB service.
3. Negotiate or use an SMB session where encrypted SMB responses are processed by the client.
4. Send crafted encrypted compound SMB responses that exceed the compound PDU limit.
5. Repeat the interaction to leak kernel memory in the client.
6. Cause denial of service through memory exhaustion, system instability, failed processes, or host reboot.

How to detect it

Look for signs that a Linux host using SMB/CIFS mounts experienced unexplained kernel memory exhaustion or instability correlated with SMB activity. Useful sources include kernel logs, system journal entries, syslog, OOM killer events, endpoint telemetry, NetFlow or firewall logs for outbound SMB connections, and SMB server access logs where available. Focus on hosts with active CIFS mounts that connected to unfamiliar, newly introduced, external, or compromised SMB servers over TCP/445 or TCP/139. Indicators are behavioral rather than uniquely fingerprinted: rising unreclaimable kernel memory, repeated OOM kills, failed allocations, CIFS/SMB client errors, reconnect loops, or host crashes shortly after encrypted SMB sessions. If packet capture is available, review SMB3 encrypted sessions with unusually large or repeated compound responses from the server immediately before memory pressure. There are no reliable public file, process, registry, or payload artifacts specific to exploitation of this issue.

What your security team should do

• Patch Linux kernels through the appropriate vendor channel and ensure systems reboot into the fixed kernel.
• Prioritize Linux servers, workstations, containers with host CIFS mounts, NAS gateways, backup systems, and application hosts that mount SMB shares.
• Restrict outbound SMB traffic to known and approved file servers; block SMB access to the internet and untrusted network segments where possible.
• Review SMB/CIFS mount inventory and remove unused or legacy mounts.
• Increase monitoring for Linux memory pressure, OOM events, kernel warnings, and unexpected instability on systems using SMB mounts.
• Investigate any SMB client host that recently experienced unexplained memory exhaustion while connected to unfamiliar or newly changed SMB servers.
• Track vendor advisories for exact fixed package versions because the input does not provide package-specific fixed versions.