Microsoft has drawn attention to a newly patched use-after-free vulnerability in the Linux kernel’s MOST USB driver, tracked as CVE-2025-40223, that can crash systems when USB devices are detached. A fix has been rolled out across multiple stable kernel branches, but Windows users who run Linux workloads—in Windows Subsystem for Linux, Azure virtual machines, or other environments—should verify their underlying kernels are up to date.

What actually happened

The flaw sits in the Media Oriented Systems Transport (MOST) USB adapter code, specifically in the hdm_disconnect routine. When a MOST-over-USB device was removed, the driver’s disconnect path called most_deregister_interface, which can trigger device_unregister. If that call dropped the last reference to the device object, the kernel immediately invoked the device’s release callback (release_mdev) to free associated memory. But the original hdm_disconnect continued executing afterward, performing additional kfree calls on already-freed structures and issuing redundant put_device operations—a textbook use-after-free race condition.

Automated kernel fuzzing by syzbot surfaced the bug with a KASAN slab-use-after-free trace. The upstream fix, written as a succinct patch of just four insertions and seven deletions, moves all resource frees into the release_mdev callback and strips the surplus put_device calls. This guarantees memory is freed exactly once and only when the device is fully released, eliminating the race regardless of refcount interleaving.

The patch was accepted through the usual kernel review channels and backported to stable kernel series: 5.10, 5.15, 6.1, 6.6, 6.12, and 6.17. Distribution vendors are now integrating these updates into their kernel packages.

What this means for Windows users

If you rely on Windows as your primary OS, you might wonder why a Linux kernel CVE matters. The answer lies in how deeply Linux is embedded in Windows ecosystems today.

For WSL2 users: Windows Subsystem for Linux 2 runs a full Linux kernel in a lightweight VM. Microsoft ships its own custom kernel for WSL2, which is built from the same upstream sources. If you are using WSL2 and have USB passthrough or attach USB devices to your Linux environment, you could be exposed. Crucially, even without direct USB passthrough, a local attacker with the ability to trigger USB events within the WSL2 VM (for example, via a compromised container or application) might exploit the race to crash the kernel, causing a denial of service.

For Azure and Hyper-V guests: Many Windows Server and Windows 11 Pro/Enterprise hosts run Linux VMs in Hyper-V. If those VMs use the MOST USB driver—whether inside IoT devices, automotive test rigs, or specialized embedded systems—the same risk applies. An attacker with low-privilege access to the guest could detach a virtual USB device and trigger the use-after-free, potentially crashing the VM.

For developers and test environments: Software developers who use Linux in VMs or on dual-boot machines for testing USB device drivers or MOST protocol interactions should treat this as a high-priority patch. The crash is reproducible, and while no public exploit demonstrates arbitrary code execution, kernel use-after-free bugs can sometimes be escalated beyond denial-of-service.

For everyday Windows users: If you never run Linux, you are not directly affected. But if you have WSL enabled (even if you rarely use it), you should ensure your WSL kernel is updated, as Microsoft often ships kernel fixes out-of-band.

How we got here: a timeline of the fix

  • Discovery: syzbot, Google’s automated kernel fuzzer, spotted a KASAN use-after-free warning in the hdm_disconnect function during stress testing with USB device attach/detach sequences.
  • Root cause analysis: Kernel developers identified that the order of device_unregister and subsequent explicit kfree calls created a window where the device could be freed while still in use.
  • Patch development: A minimal, surgical fix was crafted (commit in drivers/most/most_usb.c), relocating cleanup into the proper release callback and removing unneeded reference count tweaks.
  • Upstream acceptance: The patch was merged into the mainline Linux kernel and flagged for stable backports.
  • Stable releases: Backports landed in kernels 5.10.230+, 5.15.174+, 6.1.119+, 6.6.65+, 6.12.6+, and 6.17-rc1. Major distributions like Ubuntu, Debian, and Red Hat are shipping these versions.
  • Microsoft advisory: Microsoft published the CVE on its Security Response Center portal, signaling that the vulnerability is being tracked for its own kernel derivatives (especially WSL2). As of now, Microsoft has not released a specific WSL2 kernel advisory with a build number, but WSL2 kernels are typically updated via Windows Update or manually.

Immediate steps for Windows admins and power users

1. Check your WSL2 kernel version

Open a PowerShell or Command Prompt window and run:

wsl --version

Look for the “Kernel version” line. Compare it against the patched stable releases above. For example, if your WSL kernel is based on 6.6.x, ensure it is at least 6.6.65. Microsoft maintains its own WSL kernel source at https://github.com/microsoft/WSL2-Linux-Kernel; check there for specific security advisories.

2. Update WSL2

If a new kernel is available, update WSL2 by running:

wsl --update

You can also force a check via Windows Update: Settings → Windows Update → Check for updates. The WSL kernel often comes through as an optional update.

3. Verify your Linux VMs

For any Hyper-V or Azure Linux VMs, log into each guest and check the kernel version with uname -r. Patch according to the distribution’s normal process:
- Ubuntu: sudo apt update && sudo apt upgrade
- Debian: sudo apt update && sudo apt full-upgrade
- Red Hat / CentOS: sudo yum update kernel
A reboot is required for the new kernel to take effect.

4. Mitigations if patching is delayed

  • Disable USB passthrough in Hyper-V for untrusted Linux guests.
  • Blacklist the most_usb module inside Linux environments where MOST USB devices are not used: echo "blacklist most_usb" | sudo tee /etc/modprobe.d/blacklist-most.conf.
  • Restrict physical USB access on Windows hosts that run WSL2 with USB passthrough until kernels are updated.

5. Forensics and detection

Search kernel logs for evidence of the bug. In WSL2, you can access logs via dmesg inside the Linux environment. Look for:
- BUG: KASAN: slab-use-after-free in hdm_disconnect
- Stack traces mentioning device_unregister or release_mdev
If you find such traces, apply the patch immediately and consider reviewing what processes were running at the time.

Looking ahead

This CVE is a reminder that the boundary between Windows and Linux security is increasingly blurred. As more Windows users adopt WSL2, Azure VMs, and containerized Linux workloads, kernel-level vulnerabilities in either OS can have ripple effects across the entire IT environment. Microsoft’s inclusion of this Linux flaw on its MSRC portal suggests the company is tracking its internal kernel derivatives more closely—a positive step for transparency. Expect further advisories when Linux CVEs touch components used in Hyper-V, WSL2, or Azure Sphere.

For now, the fix is straightforward, and the exploitability window is narrow, requiring local access and specific USB interactions. Applying the kernel update quickly keeps your hybrid Windows-Linux systems safe without disrupting normal operations.