CVE-2026-52996
NoneCVSS
—
EPSS
0.2%
Published
Jun 24, 2026
CISA due date
—
Cloudanix analysis
A flaw in Linux SMB file sharing can let a remote client repeatedly consume server resources until file sharing slows down or stops working.
- Exploitation
- Remote Authenticated
- Attacker needs
- Low Privilege
- Complexity
- Moderate
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Denial of service
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Medium
What it actually does
This is a denial-of-service flaw in the Linux kernel ksmbd SMB server implementation. During SMB2 durable handle v2 open processing, ksmbd can increment the reference count of a file object when a request contains a CreateGuid that matches an existing durable open but a ClientGuid that does not match the connection. The code correctly treats that condition as “open not found” and proceeds with a new open, but previously failed to release the reference obtained during lookup. Repeated mismatched durable-handle requests can pin entries in the global file table, prevent normal close handling from running, bypass durable-handle cleanup, and cause long-lived kernel/resource leaks. The expected impact is resource exhaustion and degradation or loss of SMB file service availability, not remote code execution.
Why it matters to the business
Organizations using Linux kernel ksmbd for SMB file sharing could experience degraded file-share performance, failed file opens, exhausted server resources, or an outage that may require service restart or host reboot to recover leaked resources. The vulnerability is not listed in CISA KEV, is not reported as ransomware-used, and has a low EPSS score, but it affects an exposed network file-sharing service and can be triggered remotely by clients able to reach ksmbd over SMB. Because file shares are often operationally important, even a non-code-execution denial-of-service issue can disrupt users, applications, backups, and business workflows that depend on SMB access.
How an attack unfolds
An attacker needs network access to an SMB service backed by Linux ksmbd and the ability to send crafted SMB2 create requests using durable handle v2 create contexts. The attacker first causes or identifies a durable open associated with a specific CreateGuid, then sends repeated durable handle v2 open/reconnect-style requests that reuse that CreateGuid while presenting a different ClientGuid from the connection. ksmbd looks up the file object by CreateGuid and increments its reference count, determines that the ClientGuid does not match, and continues down the normal new-open path. In vulnerable kernels, the reference from the failed durable lookup is not released. Repeating this sequence accumulates pinned global file-table entries and prevents normal cleanup, eventually exhausting resources or impairing the SMB service. No public exploit maturity is indicated in the supplied data, and the issue is not currently known to be exploited by named threat actors or ransomware campaigns.
How to fix it
Apply a Linux kernel update from the operating system or appliance vendor that includes the ksmbd fix for the durable handle v2 ClientGuid mismatch reference leak. If kernels are self-managed, move to an upstream or vendor-maintained kernel containing the patch described as fixing “ksmbd: fix durable fd leak on ClientGUID mismatch in durable v2 open.” If immediate patching is not possible, reduce exposure by disabling ksmbd where it is not required, restricting SMB access to trusted networks and authenticated users, blocking untrusted access to TCP/445, and monitoring or limiting clients that generate abnormal SMB2 create/durable-handle traffic. Restarting ksmbd or rebooting may temporarily clear leaked resources, but it is not a durable fix because the leak can be re-triggered until the patched kernel is deployed.
How to confirm the fix worked
Confirm remediation by verifying the running kernel package or source tree includes the ksmbd durable handle v2 ClientGuid-mismatch reference-release patch. Review vendor kernel changelogs and security advisories for the fix, because the exact fixed version depends on distribution and backport policy. Confirm that ksmbd is either not loaded/enabled or is running on a patched kernel. Where safe, perform controlled validation in a non-production environment by exercising SMB2 durable handle v2 create/reconnect behavior with mismatched ClientGuid values and confirming that file references, ksmbd file-table entries, open-file counts, memory usage, and SMB service health return to baseline after connections close. Network validation should also confirm that SMB access is limited to intended sources and that TCP/445 is not unnecessarily exposed.
Typical attack path
- Identify a reachable SMB service implemented by Linux kernel ksmbd, typically over TCP port 445.
- Establish SMB2/SMB3 sessions and negotiate capabilities sufficient to use durable handle v2 create contexts.
- Create or target durable opens that cause ksmbd to maintain entries keyed by CreateGuid.
- Send repeated SMB2 create requests containing a matching CreateGuid but a different ClientGuid than the one associated with the existing durable open.
- Cause ksmbd to repeatedly take references on file objects and fail to release them on the ClientGuid-mismatch path.
- Continue the request pattern until leaked references accumulate, close handling and scavenging are defeated, and the SMB service or host experiences resource exhaustion or availability degradation.
How to detect it
To determine whether exploitation may have occurred, correlate SMB network telemetry, ksmbd service activity, and host resource behavior. Prioritize systems running ksmbd with TCP/445 exposure. Look for bursts of SMB2 CREATE traffic containing durable handle v2 create contexts, repeated reuse of the same CreateGuid from different ClientGuid values, and unusual reconnect/open patterns from one or a small number of clients. On hosts, review kernel logs, system logs, ksmbd-related service logs, EDR telemetry, and resource metrics for sustained growth in open files, kernel memory/slab usage, ksmbd file objects, or SMB sessions that do not return to baseline after clients disconnect. Operational symptoms may include failed SMB opens, client disconnects, “too many open files” style errors, memory pressure, soft lockups, or recovery only after restarting services or rebooting. Packet captures or Zeek/Suricata-style SMB metadata are especially useful because the exploit condition is protocol-level: a durable handle v2 request where CreateGuid matches an existing open but ClientGuid differs. Absence of public exploitation signals, KEV listing, or ransomware association lowers urgency relative to actively exploited bugs, but it does not rule out targeted or opportunistic denial-of-service attempts.
- ksmbd
- ksmbd.mountd
- TCP/445
- SMB2_CREATE
- SMB2_CREATE_DURABLE_HANDLE_REQUEST_V2
- DH2Q
- DH2C
- CreateGuid
- ClientGuid
- Too many open files
- too many open files
- cannot allocate memory
- Out of memory
- Memory allocation failure
- soft lockup
- hung task
What your security team should do
- Inventory systems that run Linux kernel ksmbd and expose SMB services, prioritizing internet-facing, partner-facing, and broadly reachable internal file servers.
- Patch affected kernels through the appropriate Linux distribution, appliance, or vendor update channel as soon as operationally feasible.
- If patching is delayed, disable ksmbd where unnecessary or restrict TCP/445 access to trusted networks and required clients only.
- Add monitoring for abnormal volumes of SMB2 CREATE requests using durable handle v2 create contexts, especially repeated CreateGuid reuse across differing ClientGuid values.
- Monitor ksmbd hosts for rising open-file counts, kernel memory pressure, stuck file-table entries, SMB open failures, and service degradation that improves only after restart or reboot.
- Review kernel, system, and SMB telemetry for signs of prior resource-exhaustion attempts since publication, especially on externally reachable SMB services.
- Document whether the organization uses kernel ksmbd versus Samba userspace smbd, because this issue is specific to ksmbd.
The record
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix durable fd leak on ClientGUID mismatch in durable v2 open ksmbd_lookup_fd_cguid() returns a ksmbd_file with its refcount incremented via ksmbd_fp_get(). parse_durable_handle_context() in the DURABLE_REQ_V2 case properly releases this reference on every path inside the ClientGUID-match branch, either by calling ksmbd_put_durable_fd() or by transferring ownership to dh_info->fp for a successful reconnect. However, when an entry exists in the global file table with the same CreateGuid but a different ClientGUID, the code simply falls through to the new-open path without dropping the reference obtained from ksmbd_lookup_fd_cguid(). Per MS-SMB2 section 3.3.5.9.10 ("Handling the SMB2_CREATE_DURABLE_HANDLE_REQUEST_V2 Create Context"), the server MUST locate an Open whose Open.CreateGuid matches the request's CreateGuid AND whose Open.ClientGuid matches the ClientGuid of the connection that received the request. If no such Open is found, the server MUST continue with the normal open execution phase. A CreateGuid hit with a ClientGUID mismatch is therefore the "Open not found" case: proceeding with a new open is correct, but the reference obtained purely as a side effect of the lookup must not be leaked. Repeated requests that hit this mismatch pin global_ft entries, prevent __ksmbd_close_fd() from ever running for the corresponding files, and defeat the durable scavenger, leading to long-lived resource leaks. Release the reference in the mismatch path and clear dh_info->fp so subsequent logic does not mistake a non-matching lookup result for a reconnect target.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|