CVE-2025–38561 is a race condition vulnerability that was identified in Linux Kernel's ksmbd (in-kernel SMB server) component with a CVSS3.1 base score of 7.0. It was discovered on August 19, 2025 and disclosed publicly on September 24, 2025.

The flaw lies in the handling of sess->Preauth_HashValue during the SMB2 session setup request. Since there is no synchronization around freeing or modifying this memory during setup, concurrent session setup requests can lead to a race condition (one thread might free or reallocate the memory while another is still accessing it).

This means, an attacker who can issue multiple simultaneous session setup requests (after authentication) can exploit this race condition to corrupt kernel memory and potentially, achieve arbitrary code execution.

Affected kernels

Any Linux kernel that includes the in-kernel SMB server ksmbd and does not contain upstream fix from git commit 44a3059c4c8cc635a1fb2afd692d0730ca1ba4b6 is affected.

Mitigation

The upstream fix for this vulnerability was committed in git commit 44a3059c4c8cc635a1fb2afd692d0730ca1ba4b6 (ksmbd: fix Preauth_HashValue race condition)and has been back-ported into several stable kernel trees. Many distributions have already released, or will soon release patched kernel packages.

On Debian-based systems, you can verify whether your kernel includes the patch by checking the package changelog:

apt changelog linux-image-$(uname -r) | grep ksmbd

The only mitigation is to upgrade to a patched version as early as possible.

In the section below, I will be discussing the minimal PoC (Proof of Concept) for CVE-2025–38561 that can be found here.

Proof Of Concept

As of October 9, 2025, Debian 11, 12 and 13 have been patched. Ubuntu distros are vulnerable to the said CVE. Naturally, we used — Ubuntu 22.04 for its vulnerable kernel and Debian 13 for its patched kernel to compare results.

Since it is a kernel vulnerability, 2 Virtual Machine instances with the following configurations were used:

Vulnerable Instance

• Distribution: Ubuntu 22.04.5 LTS
• Kernel: 5.15.0–157-generic
• Architecture: ARM64
• Cores: 1
• RAM: 1024 MB
• IP: 192.168.0.132

Patched Instance

• Distribution: Debian (Trixie) 13.1
• Kernel: 6.12.48+deb13-arm64
• Architecture: ARM64
• Cores: 1
• RAM: 1024 MB
• IP: 192.168.0.224

Ubuntu server and Debian minimal installation were used.

All set, let us get to the PoC. We begin by cloning the git repository on the instance and navigating into the cloned directory.

git clone https://github.com/toshithh/CVE-2025-38561
cd CVE-2025-38561

Before proceeding further, we need to escalate ourselves to root. On Debian, it can be done using

su root

and on Ubuntu,

sudo su

The folder contains a setup.sh file. This file installs the required packages, loads the ksmbd kernel module and enables guest access to the SMB server. To set up,

chmod +x setup.sh
./setup.sh

To verify if the ksmbd server works, we can try listing the shares using smbclient or just check if port 445 is enabled using netstat.

smbclient -L //localhost/ -N
#OR
netstat -tulnp | grep 445

Optional

There are two binary files — negotiate.bin and session_setup.bin in this directory, which are actually SMB packets captured through wireshark. These were used because otherwise, the ksmbd implements a strict check on the packet and discards the packets which do not match its criterion.

To capture these packets,

• Start a wireshark session on your host machine and monitor the network traffic.
• List shares on the target server (192.168.0.132 in my case) using smbclient.
• Finally, stop the wireshark session using

smbclient -L //192.168.0.132/ -N

Then find the negotiation request and session setup requests and export their packets as depicted below.

Exploit

With the basic setup complete, execute exploit.py specifying the target IP and number of concurrent connections to use to achieve the race condition. The vulnerable server gets stuck while the patched server just drops the broken connections.

python3 exploit.py 192.168.0.132 512

The screenshot below shows the difference between the execution of the exploit on a vulnerable vs a patched server.

The vulnerable server reaches the race condition quickly due to incomplete session setup requests and all connections get stuck while the patched server treats and discards them according to the synchronized mechanism.

The time for execution on both the instances confirms it. Although both the instances have the same configuration, the vulnerable instance quickly reaches race condition and there is a denial of service instantly within a minute.

On the patched instance, the server discards the sess->Preauth_HashValue in the end and there is proper synchronization. Hence, it takes 11 minutes to complete all requests (due to exhaustion of resources)!