Microsoft has published an advisory for CVE-2025-68372, a use-after-free vulnerability in the Linux kernel’s Network Block Device (NBD) driver that can crash systems running affected kernels, including those used in Windows Subsystem for Linux 2 (WSL2) and Azure virtual machines. The flaw, which stems from a race condition in how the driver handles configuration references, allows a local attacker to trigger memory corruption and denial of service. Upstream kernel fixes are already available, and Microsoft is coordinating updates for its Linux-based products.
A Race Condition in the Network Block Device
The bug lives in the NBD driver, a kernel module that lets Linux systems treat remote block devices as though they were local disks. It’s commonly used for network-attached storage, virtual machine disk provisioning, and in cloud environments. The vulnerability arises when a worker thread—responsible for handling incoming NBD control messages—accesses a configuration object that has already been freed because another operation dropped the reference count too early.
Here’s what happens in simple terms: The driver uses reference counting to keep track of how many threads are using a configuration structure. A function called recv_work runs on a kernel workqueue and relies on that configuration staying alive for its entire execution. Before the fix, the code would release the configuration before the worker was safely finished, opening a tiny window where memory could be freed and then still used—a classic use-after-free.
Public trackers describe two common interleavings of control operations (connect, open, clear socket, reconfigure, close) that can trigger the bug. In both, a second recv_work instance or an ioctl call mistakenly drops the last reference while the first worker is still active, leading to a kernel crash when the freed memory is accessed.
The Fix: A One-Line Reorder
The upstream patch, authored by Zheng Qixing and driven by the automated fuzzing tool syzbot, is minimal but effective. In drivers/block/nbd.c, the call to nbd_config_put—which releases the configuration reference—has been moved from before a wake-up call to after it. Previously, the code:
- Woke up any waiters on a completion queue.
- Then called
nbd_config_put, freeing the config if it was the last reference.
Now, the nbd_config_put happens after the wake-up and after an atomic decrement, ensuring the configuration remains valid for the entire lifetime of the worker thread. The change is literally one line: reordering the function call so that the reference is not dropped while recv_work might still be executing.
This fix undoes a previous change that had moved the config_put earlier in an attempt to prevent a different race. That earlier commit had solved a hung-task bug but inadvertently introduced the use-after-free. The new patch restores correct ordering while relying on an existing flush_workqueue call to avoid the old deadlock.
Who Is Affected and What’s at Stake
Anyone running a Linux kernel with the NBD driver is potentially vulnerable, but the practical risk depends on how the system is used.
For Windows users running WSL2:
WSL2 includes a full Linux kernel, and NBD is typically compiled as a module. If you use NBD for network storage or run custom kernel configurations that load the module, you could be at risk. Most home users who simply run a default WSL2 distribution probably do not load nbd, so the immediate danger is low. However, if an attacker has local access to your machine—even with limited privileges—they could load the module and trigger the bug to crash your WSL environment or the host kernel (in some configurations).
For Azure administrators:
Azure offers a variety of Linux images that may include the nbd module. Virtual machines that attach network block storage or run container environments that use NBD for volume mounting should be patched promptly. A crash in a production VM can disrupt services and lead to downtime.
For on-premises Linux admins:
Any server that uses NBD for block device sharing—in test labs, storage appliances, or orchestration tools—is affected. Multi-tenant environments where less-trusted users can create NBD connections are particularly exposed.
Severity and exploitability:
The CVSS v3 base score from SUSE is 5.5 (medium), focusing on availability impact. The attack vector is local, and some privileges are required (typically CAP_SYS_ADMIN or sufficient rights to manipulate NBD control interfaces). While no public proof-of-concept exploit has been seen as of this writing, kernel use-after-free bugs are prized by attackers because they can sometimes be leveraged for privilege escalation. For now, the most likely real-world effect is denial of service: a crash that forces a reboot.
From Bug to Patch: A Timeline
The flaw was discovered by syzbot, an automated kernel fuzzer, and reported to the Linux kernel community. A fix was quickly developed and merged upstream. The following table shows the fixed kernel versions, according to the OSV vulnerability database:
| Kernel Branch | Fixed Version |
|---|---|
| 6.12 (longterm) | 6.12.63 |
| 6.17 (stable) | 6.17.13 |
| 6.18 (stable) | 6.18.2 |
Microsoft acknowledged the issue in its Security Update Guide, though the advisory page currently contains only generic legal text. The company is expected to backport the patch into the WSL2 kernel package, which updates through Windows Update. Major Linux distributors (SUSE, Debian, Ubuntu, Red Hat) are also preparing or have released their own patched kernels.
Steps to Protect Your Systems
1. Check your exposure
Determine whether the nbd module is loaded and whether your kernel is vulnerable. On Linux or WSL2, run:
uname -r
lsmod | grep nbd
If the module is listed, you are at risk until you patch. Even if it’s not loaded, an attacker could potentially load it, so patching is still recommended.
2. Apply the update
- For WSL2 users: The kernel update is delivered via Windows Update. Run wsl --update from PowerShell or Command Prompt to fetch the latest WSL2 kernel. After updating, verify the new version with uname -r inside your Linux distribution.
- For Azure VMs: Use your distribution’s package manager to install the latest kernel packages. For example, on Ubuntu: sudo apt update && sudo apt full-upgrade. Reboot after installation.
- For on-premises systems: Upgrade to a kernel version listed in the table above, or apply the patch manually if you compile your own kernel. Wait for your vendor’s official advisory if you run a custom distribution.
3. Temporary mitigation if you can’t patch immediately
- Blacklist the module to prevent it from loading:
bash
echo "blacklist nbd" | sudo tee /etc/modprobe.d/nbd-blacklist.conf
- If the module is already loaded and you can safely unload it, run:
bash
sudo rmmod nbd
Warning: This will disrupt any active NBD devices. Unmount any NBD-backed filesystems first.
- Restrict access to the CAP_SYS_ADMIN capability for untrusted users, and monitor system logs for nbd-related errors or kernel oops messages.
4. Verify the fix
After patching, check that the module no longer exhibits the bug. Load nbd (if needed) and verify that no use-after-free warnings appear in dmesg. Also confirm the kernel version matches a fixed one.
What Comes Next
Concurrency bugs in kernel drivers are not going away, and the NBD module is just one piece of a complex puzzle. As Linux continues to underpin everything from cloud workloads to embedded devices, administrators should treat even medium-severity CVEs as high-priority for patching. Microsoft’s involvement in tracking this CVE signals the growing overlap between Windows and Linux security landscapes—a trend that will only accelerate with WSL2’s deep kernel integration.
For now, the takeaway is clear: patch your Linux kernels, whether they run on metal, in a VM, or inside WSL2. The update is simple, and the alternative is an unnecessary crash risk.