Linux Kernel Fix: ksmbd Session Refcount Leak (CVE-2025-40285)

A small but important kernel fix landed this week to close CVE‑2025‑40285 — a reference‑counting bug in the Linux kernel’s in‑kernel SMB server that could leak a ksmbd session object when a session reconnects. The patch adds a missing ksmbd_user_session_put in smb2_sess_setup, closing a race / lifecycle gap that could otherwise accumulate leaked ksmbd_session references and, under sustained triggering, cause resource exhaustion and availability problems.

Background / overview​

ksmbd is the kernel‑space SMB (Server Message Block) server implementation used on many Linux systems to serve SMB/CIFS shares directly from the kernel. Because ksmbd runs in kernel-space, bugs in its session and object lifetime handling can have outsized operational impact — typically availability and reliability, and in the worst case a vector that contributes to memory corruption chains. The newly recorded CVE describes a refcount leak in smb2_sess_setup, the code path that establishes SMB2 sessions; when sessions require reconnecting, a missing release call can leave a ksmbd_session object referenced longer than intended, slowly leaking kernel memory. The registries and vulnerability aggregators (NVD, OSV, CVE feeds) list the defect as fixed upstream; the technical fix is to add the missing ksmbd_user_session_put to ensure the session’s user/session reference is balanced during reconnect flows. Public vulnerability records confirm the description and point to the upstream stable commits that implement the change.

---

Why this matters: practical impact and attack model​

• Primary impact — Availability. A reference‑count leak in kernel code typically presents as steadily increasing memory usage tied to the leaked object type (here, ksmbd_session). If the leak is triggered repeatedly by untrusted or misbehaving clients, the host can experience increased kernel memory pressure and eventually resource exhaustion, resulting in kernel instability, OOM events, or service loss. This is the most likely real‑world outcome reported for this class of defect.
• Attack surface — local or network‑adjacent. The exploitability depends on how ksmbd is exposed. If the kernel SMB server is reachable to remote or untrusted clients (for example, a network‑facing file server or appliance), an attacker controlling an SMB peer can repeatedly exercise the reconnect flow and accelerate the leak. In other deployments ksmbd might only be reachable locally, which reduces exposure. Aggregators classify the vector as local/network‑adjacent and the practical risk as medium because exploitation to cause availability loss is fairly straightforward under the right topology.
• Not a confirmed RCE. There is no authoritative public evidence the bug creates a direct remote code‑execution primitive; the documented failure mode is a lifecycle/refcount leak leading to resource exhaustion and availability disruption rather than an immediate memory‑corruption primitive that yields remote code execution. That distinction doesn’t make the issue unimportant — kernel availability bugs matter in production — but it does change priority and mitigation tradeoffs.

---

Technical anatomy: what went wrong, in code terms​

At a simplified level the error is a missing release in one control path. When the SMB2 session setup code handles a reconnect scenario, the code previously failed to call ksmbd_user_session_put in all paths where the session/user reference should have been dropped. The missing put means the reference count (kref-style or equivalent) on the ksmbd_session user object can remain incremented after the server believes the session was torn down or reattached.
Two things make reference leaks in kernel code dangerous:

• The kernel runs long‑lived processes; leaks accumulate across events that happen frequently in production (reconnects, failed handshakes, or churned client sessions).
• Leaked kernel objects live in privileged memory; while leaks alone are primarily an availability problem, they lower the bar for attackers to combine with other issues (for example, predictable allocation reuse) if they attempt a more complex chain.

The upstream fix is surgical and minimal: add the missing ksmbd_user_session_put where the previous control flow could bypass it. That ensures each hold or kref_get is matched by a corresponding put, restoring correct lifecycle semantics. Upstream commit references are present in public trackers and were merged into the stable kernel branches.

---

Affected systems and patched kernel versions​

Public vulnerability trackers list this as a Linux‑kernel issue and map it to the stable kernel trees. Several patch‑tracking sites indicate the fix has been applied across the supported stable branches; some aggregators report the fix appears in the following stable kernels (downstream vendor mapping may vary):

• 6.1.159
• 6.6.117
• 6.12.59
• 6.17.9

Those kernel version numbers come from the stable backport merges and aggregator summaries; operators must not assume their distro is patched simply because upstream lists a stable commit — distributions often backport fixes differently and ship distinct package versions. Always confirm the package changelog or vendor advisory for the exact package version that contains the backport for your distribution. Which installations are highest priority?

• Network‑facing hosts running ksmbd (kernel SMB server) that accept untrusted clients.
• Multi‑tenant systems and shared hosts where untrusted workloads can establish SMB sessions against a local ksmbd instance.
• Appliances, vendor images, and embedded devices whose kernels are maintained externally and where patch cadence may be slow.

For desktop systems or servers that do not run ksmbd or expose SMB‑serving functionality, exposure is lower — but remember that container hosts and virtual appliances inherit the host kernel, so host kernel bugs can affect container workloads.

---

Detection, hunting and observability guidance​

This class of bug produces operational traces you can hunt for:

• Kernel memory growth patterns tied to ksmbd or kernel SMB state. Watch for steadily increasing cache/object counts that correlate with SMB session churn.
• Kernel logs (dmesg / journalctl -k) that show ksmbd warnings, OOM events, or service instability around SMB session management.
• Application‑level confusion where client reconnects succeed but server resources do not drop; for example, many ghosted session entries visible through diagnostic tools.

Practical commands and checks:

• Inspect kernel logs after an observed incident:
• journalctl -k --no-pager | egrep -i 'ksmbd|smb2|smbd|ksmb'
• Monitor kernel memory and object counts over time (e.g., slabtop, /proc/slabinfo) and correlate with SMB session churn.
• If you can reproduce in a lab, exercise repeated session reconnects and watch for monotonic increases in memory tied to ksmbd session objects.

Because kernel WARNs and leaks can be subtle and transient, collect dmesg and vmcores centrally and preserve artifacts for vendor triage if needed.

---

Remediation and mitigation — a prioritized operational playbook​

• Inventory: Identify all hosts in your estate that run ksmbd or any kernel SMB server functionality. Query package lists, kernel module loads, and configuration management data to find candidates. If ksmbd is not present, confirm whether any other kernel SMB implementation (or userspace SMB servers) could surface similar behavior.
• Patch: Apply vendor or distribution kernel updates that include the upstream fix. Because this is a kernel change, updates require rebooting into the patched kernel. Confirm the vendor advisory or package changelog specifically references the upstream commit or CVE mapping before wide deployment. If you maintain custom kernels, pull the upstream stable commits into your tree and rebuild.
• Short‑term mitigations when patching is delayed:
• Disable or restrict access to the kernel SMB server (ksmbd) on hosts that do not need it.
• Limit which clients can connect to SMB exports via network ACLs or firewall rules — prioritize blocking untrusted or public networks.
• Where possible, remove or blacklist the ksmbd kernel module until patched images are available.
• Rate‑limit or otherwise control automations that repeatedly trigger reconnects to reduce the speed at which a leak can exhaust resources.
• Validate: After patching, execute representative session churn tests in a staging environment to ensure the leak no longer reproduces, and monitor kernel logs for regressions.
• Vendor follow‑up: For appliances and vendor kernels, request explicit backport confirmation. Vendors must confirm their supplied images or firmware include the fix; do not assume vendor images are patched until the vendor states so.

---

Vendor responses and Microsoft note​

Public registries indicate the Linux vendor/maintainers assigned CVE‑2025‑40285 and the fix is merged into the stable trees. Several aggregators list the NVD/OSV entries that describe the exact remediation action — adding ksmbd_user_session_put — and point to the stable commits. Microsoft’s Security Response Center has used CSAF/VEX attestations in similar CVE rollouts to identify which Microsoft‑distributed Linux artifacts contain vulnerable upstream components; previous disclosures demonstrate Microsoft may initially attest only a subset (for example, Azure Linux) and expand attestations over time. Administrators running Microsoft‑supplied Linux artifacts — WSL2 kernels, CBL‑Mariner based images, Azure Marketplace images — should treat Microsoft attestations as authoritative for the attested SKUs but independently validate non‑attested images in their estate. File‑level tracking and product attestations are useful automation signals but are not a substitute for inventory checks.

---

Risk appraisal — strengths of the fix and residual caveats​

Strengths

• The remediation is minimal and targets the root cause: balancing the reference count by adding the missing put is a straightforward correctness fix with low regression risk.
• Small, surgical fixes are easier to backport and ship quickly across multiple stable kernel branches and distributions. This reduces the window where unpatched deployments remain exposed.

Residual risks and caveats

• Distribution backport policies vary: some enterprise distros may take extra time to test and ship backports. Appliances and embedded devices with infrequent firmware updates remain a key concern.
• A refcount leak is primarily an availability problem, but availability failures in multi‑tenant or critical infrastructure can have cascading business impact. Treat such CVEs with operational urgency in high‑value contexts.
• There are no publicly published weaponized exploits for this CVE at the time of this writing, but lack of proof of exploitation does not mean exploitation is impossible — especially for kernel issues where chains often require additional primitives. Continue to monitor threat feeds and vendor incident reports.

---

Practical verification checklist (for administrators)​

• Confirm whether ksmbd is enabled:
• lsmod | egrep -i 'ksmbd|smb'
• Check systemd services and distribution packaging for kernel SMB options.
• Verify kernel package change log:
• On RPM: rpm -q --changelog kernel | egrep -i 'CVE-2025-40285|ksmbd|smb2_sess_setup'
• On Debian/Ubuntu: apt changelog linux-image-$(uname -r) or check the distro security tracker.
• If running a custom kernel, ensure the upstream commit that adds ksmbd_user_session_put is present in your tree.
• After patch & reboot, run a controlled reconnect/stress scenario and monitor:
• journalctl -k
• slabtop and /proc/slabinfo for ksmbd_session or similar object counts
• dmesg for unexpected WARNs or OOM-related messages.
• For vendor appliances: obtain an explicit statement or firmware image ID that includes the backport.

---

Final takeaways​

CVE‑2025‑40285 is an important but fixable kernel correctness bug: a missing reference release in smb2_sess_setup could leak ksmbd_session references when sessions reconnect, producing a cumulative resource leak and service disruption. The upstream patch is simple — add the missing ksmbd_user_session_put — and has been merged into the stable kernel branches. Operators should prioritize patching network‑facing ksmbd servers, multi‑tenant hosts, and any appliance images that expose kernel SMB services, but must validate vendor advisories and package changelogs before declaring systems patched. Prompt application of kernel updates, paired with short‑term mitigations (disable or restrict ksmbd where possible), is the pragmatic path to reducing operational risk.

---

Summary of the most load‑bearing facts you can act on immediately:

• The bug is a refcount leak in smb2_sess_setup that was fixed by adding ksmbd_user_session_put.
• Upstream stable merges and public vulnerability records show the fix is available; distributions will map those commits into package updates — verify package changelogs.
• Prioritize patching hosts running ksmbd or exposing kernel SMB services; implement network restrictions and module disablement where immediate patching isn't possible.

This article has summarized the technical change, operational impact, and practical remediation steps for CVE‑2025‑40285 using public advisory records and upstream patch summaries; verify package-level mappings from your distro or vendor before rolling changes into production.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center