Linux kernel maintainers have quietly shipped a fix for a reference-counting leak in the kernel’s SMB server component, ksmbd, that could allow an attacker to slowly exhaust system memory and trigger server crashes. Designated CVE-2025-40285, the bug was addressed by adding a single missing function call—ksmbd_user_session_put—in the SMB2 session setup code path. While the vulnerability does not enable remote code execution, it poses a genuine availability risk for any Linux system running ksmbd and serving SMB shares to untrusted clients.

The Patch Details

The kernel SMB server, or ksmbd, handles session creation and tear-down for SMB file sharing directly within kernel space. During a session reconnect, the smb2_sess_setup function failed to properly release a reference to a user session object in one particular flow. This oversight meant that every time a client re-established a session, the kernel would hold onto a reference that should have been dropped, slowly leaking a small amount of memory.

The fix, now merged into the upstream stable kernel trees, is surgically precise: it inserts the missing ksmbd_user_session_put call to balance the reference count. In kernel programming, reference counts are used to track how many parts of the code are using an object. When the count reaches zero, the object is freed. A leak like this keeps the count permanently above zero, so the object and its memory are never reclaimed.

Kernel memory leaks are particularly insidious because the kernel runs indefinitely and the leak accumulates over time with each trigger—in this case, every SMB2 session reconnect. Under normal conditions the leak might go unnoticed, but a determined attacker can repeatedly send reconnect requests, accelerating memory loss and eventually forcing the system into an out-of-memory state.

The fix has been backported to several longterm and stable kernel branches. According to public tracking data aggregated by vulnerability databases, the following upstream kernel versions include the patch:

  • 6.1.159
  • 6.6.117
  • 6.12.59
  • 6.17.9

Keep in mind that Linux distribution vendors often backport security fixes into their own kernel packages, so your system may run a kernel version that doesn’t match these numbers exactly but still includes the fix. Always check your distribution’s security advisory and the kernel changelog for confirmation.

Who Is Affected and How to Check

If you run a Linux server that provides SMB file shares to remote clients using ksmbd, you are potentially vulnerable. The risk is highest for systems where ksmbd is exposed to untrusted networks—for example, a public-facing file server, a multi-tenant environment, or an edge appliance. Desktop and development machines that don’t run ksmbd or block SMB traffic at the firewall are at lower risk, but it’s still wise to verify.

To determine if ksmbd is active on your system, open a terminal and run:

lsmod | grep ksmbd

If you see output, the module is loaded. You can also check for the ksmbd service or kernel config option. If ksmbd is not present and you aren’t using any kernel SMB serving functionality, your immediate exposure is minimal.

The primary impact of this bug is availability loss. When the memory leak is exploited, the system will exhibit escalating kernel memory pressure, which can manifest as sluggish performance, OOM (out-of-memory) kills of critical processes, or a complete kernel panic. VMware, cloud instances, and containers that rely on the host kernel are all susceptible, because the leak occurs in shared kernel memory.

Importantly, there is no evidence that this bug can be leveraged for remote code execution. The vulnerability is strictly a resource exhaustion issue. However, in production environments where reliability is paramount, an availability attack can be just as damaging as a remote access exploit.

Microsoft, which maintains its own Linux-based products such as Azure Linux and the Windows Subsystem for Linux (WSL2) kernel, published an advisory through its Security Response Center to alert customers of products that might include the vulnerable ksmbd code. Administrators of Microsoft-supplied Linux artifacts should check MSRC’s update guide for specific attestations and package version mappings.

What You Should Do Right Now

  1. Inventory your systems. Identify every Linux host that runs ksmbd. Use your configuration management tools or scan for the module. Don’t forget appliances, virtual machines, and container hosts—they all share the kernel.

  2. Apply updates. If your distribution has released a kernel update that addresses CVE-2025-40285, apply it immediately and reboot. On Red Hat, CentOS, or Fedora:
    sudo dnf update kernel
    On Debian or Ubuntu:
    sudo apt update && sudo apt upgrade
    After rebooting, verify the new kernel version with uname -r and check the changelog for any mention of CVE-2025-40285 or ksmbd_user_session_put.

  3. Mitigate if you can’t patch. If updating the kernel is not immediately possible, you can disable ksmbd temporarily:
    - Unload the kernel module: sudo rmmod ksmbd (if it’s not built-in)
    - Stop any ksmbd services and mask them to prevent auto-start
    - Use firewall rules to block access to SMB ports (typically 139 and 445) from untrusted networks

These mitigations reduce the attack surface while you test and schedule a proper update.

  1. Validate the fix. In a staging environment, simulate repeated SMB session reconnects—for instance, using a scripted smbclient loop—and monitor kernel memory usage with slabtop or by reading /proc/slabinfo. Look for any growth in ksmbd-related slabs. After patching, the leak should stop.

  2. Check vendor appliances. If you’re using a storage appliance, a network-attached storage device, or a vendor-supplied Linux image, confirm with the manufacturer that their firmware includes this fix. Do not assume that an upstream commit automatically propagates to their product.

How We Got Here

ksmbd was introduced into the Linux kernel in version 5.15 as a high-performance in-kernel SMB server, designed to offer a lighter alternative to the userspace Samba suite for specific use cases. Because it runs in kernel space, any memory management bug carries greater weight: a small leak can turn into a system-wide stability problem far more quickly than in a userspace daemon.

This particular bug appears to have been present for some time but wasn’t widely noticed because memory leaks in session handling often require deliberate, repeated triggering. In many deployments, SMB session reconnects are infrequent, so the leak stayed under the radar. The vulnerability was eventually identified and responsibly disclosed, leading to a coordinated fix through the kernel’s stable release process.

The Microsoft Security Response Center advisory confirms the fix and notes that it applies to certain Microsoft-distributed Linux artifacts, such as Azure Linux and WSL2 kernels. Organizations relying on these should consult the MSRC update guide for specific package version mappings.

Looking Ahead

This CVE reinforces two enduring lessons for system administrators: kernel-level services require rigorous patch management, and exposure should be minimized wherever possible. With the rise of containerized environments and edge computing, more systems than ever are running Linux kernels that provide network services—often without the operator’s full awareness.

Look out for further advisories from your distribution, especially if they use a rolling release or a custom kernel. The Linux kernel security team and distributions are expected to continue hardening ksmbd, and this fix may be succeeded by additional cleanups in the same code area. If your threat model includes a malicious SMB client, consider network segmentation, traffic rate limiting, and intrusion detection signatures that flag abnormal session reconnect patterns.

While no public exploits for CVE-2025-40285 have been reported yet, the low complexity of the attack means that one could surface soon. A working exploit would simply automate the session reconnect loop, making it trivial for attackers to weaponize. Patching now is the most effective defense.

For teams managing large fleets, tools like kernel live patching (e.g., KernelCare, ksplice, or kpatch) can apply this fix without a reboot on supported distributions, although the specific patch must still be integrated by the live patching vendor. As always, test in a non-production environment first.

Staying ahead of kernel vulnerabilities is a shared responsibility. By combining timely updates, proactive monitoring, and defense-in-depth, you can prevent a small coding mistake from becoming a major operational incident.