Linux KernelOperating system · Linux
CVE-2026-52996
Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.
NVD · uneditedIn 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.
Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.
dbcve analysis · high confidenceIn ksmbd (Linux kernel SMB server), when processing a durable v2 handle request, ksmbd_lookup_fd_cguid() increments a file's refcount. If a CreateGuid matches but ClientGuid differs, the code correctly proceeds to create a new open but incorrectly fails to release this reference. Each mismatched request leaks the file reference, accumulating over time and preventing file cleanup.
Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.
Affected products & versions What the vendor confirmedThe version ranges the vendor confirmed as vulnerable. If your version sits inside a range here, treat yourself as exposed until you have upgraded.
NVD · CPE data
Linux KernelOperating system
>= 6.6.32, < 6.6.141>= 6.9, < 6.12.91>= 6.13, < 6.18.33>= 6.19, < 7.0.10CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.
From the vector- Attack vector
- Local
- Complexity
- Low
- Privileges
- Low
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- None
- Integrity
- None
- Availability
- High
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.
dbcve checksWork through these to decide whether this CVE applies to you.
-
Verify ksmbd is loadedCheck if the ksmbd kernel module is loaded by running 'lsmod | grep ksmbd' or check if ksmbd is active via 'cat /proc/fs/ksmbd/server_info'Affected if ksmbd module is loaded and serving SMB connections
-
Check kernel versionRun 'uname -r' to get the running kernel version and compare against affected ranges: 6.6.32 to 6.6.140, 6.9 to 6.12.90, 6.13 to 6.18.32, 6.19 to 7.0.9Affected if Kernel version falls within any of the affected ranges listed
-
Monitor open file handle countIf ksmbd is running, monitor the number of open file handles over time using 'ls /proc/*/fd | wc -l' or check per-process fd count for ksmbd processes with 'ps -C ksmbd -o pid=' and then 'ls /proc/<pid>/fd'Affected if Open file handle count grows steadily without returning to baseline after SMB operations complete
-
Check for resource exhaustionMonitor for symptoms of resource exhaustion: run 'dmesg' for out-of-memory or file table exhaustion errors, and check 'cat /proc/sys/fs/file-nr' for growing allocated file handlesAffected if File handle count in /proc/sys/fs/file-nr steadily increases or dmesg shows file table exhaustion errors while ksmbd is active
Environment is affected if ksmbd is running on a kernel version within the affected ranges AND symptoms of file handle accumulation are observed.
Generated from the published advisory. Verify against your own configuration.
Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.
dbcve · scoped6.6.1416.12.916.18.33
Apply the kernel patch to release the reference in the ClientGuid mismatch path and clear dh_info->fp. Monitor for resource exhaustion if systems cannot be patched promptly.
- 1. Identify the running Linux kernel version using 'uname -r' or 'cat /proc/version'
- 2. Determine which version branch the running kernel belongs to (6.6.x, 6.9.x, 6.13.x, or 6.19.x)
- 3. For kernels in the affected range, apply the upstream kernel patch that fixes the reference leak in parse_durable_handle_context()
- 4. The patch adds proper reference release in the ClientGUID mismatch path by calling ksmbd_put_durable_fd() and clearing dh_info->fp
- 5. Rebuild and reboot the kernel, or apply the distribution-specific kernel update when available
- 6. Verify the fix by checking the git commit (e.g., checking the source file ksmbd/transport_ipc.c for the corrected logic)
Generated from the published advisory — verify against the referenced sources before acting.
Fix this in Linux Kernel
Scoped from the published advisory
- Consultation2.0 h
- Implementation4.0 h
- Testing8.0 h
- Review / QA3.0 h
An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $4,576.
Scan for this in your stack
Free · runs locallyCheck whether your project pulls in CVE-2026-52996 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.
References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.
Primary sourcesPractitioner notes
ContributedPeer-ranked notes from engineers who’ve handled CVE-2026-52996 in production — separate from our analysis above.
The advisory tells you what broke. It rarely tells you what actually worked. If you’ve dealt with this one, that detail is what the next engineer is searching for.
- The version that genuinely resolved it — not the one the vendor claimed
- A config change or rule that shut the vector down
- A gotcha in the upgrade path that cost you an afternoon
No notes yet
Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.
A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.
- Verified mitigations, workarounds, and config changes
- Version or environment caveats, and links to real fixes
- No weaponised exploit code, or anything meant to cause harm
- No spam, self-promotion, credentials, or personal data