Microsoft on June 5, 2025 confirmed that its Azure Linux distribution is vulnerable to a Linux kernel bug tracked as CVE-2025-38460, a flaw that could let local attackers crash systems by exploiting a null pointer dereference in the ATM CLIP networking code. But the advisory, published on the Microsoft Security Response Center (MSRC) portal, conspicuously omits any mention of Windows Subsystem for Linux 2—even though WSL2 ships with a Microsoft-maintained kernel that may contain the exact same defective code.

For Windows users who rely on WSL2 for development, testing, or DevOps workflows, this silence raises an immediate question: does the kernel that powers their Linux environments carry the same vulnerability, and if so, why hasn’t Microsoft said so?

The answer is nuanced, but the practical takeaway is clear: if you run WSL2 on your Windows machine, you should check your kernel version today.

The flaw: a null pointer dereference in a forgotten networking stack

CVE-2025-38460 originates in the Linux kernel’s ATM (Asynchronous Transfer Mode) CLIP (Classical IP over ATM) subsystem, a relic of early broadband networking that most users will never encounter. The bug resides in the toatmarpd helper function, which can be called from unsleepable contexts via clipneighsolicit and neighops->solicit. Without proper locking, a racing condition could lead to a null pointer dereference, crashing the kernel.

Upstream kernel maintainers deployed a fix that introduces a private mutex and RCU protection to guard the pointer. The patch was backported to multiple stable kernel branches:

  • 5.4.296
  • 5.10.240
  • 5.15.189
  • 6.1.146
  • 6.6.99

Any kernel version older than these within the respective series is vulnerable—provided the ATM CLIP code was compiled into the running kernel.

The vulnerable code is part of the mainline Linux kernel source tree, but it must be enabled via kernel configuration settings (CONFIGATM and CONFIGATMCLIP). If those options are not set to y (built-in) or m (module), the kernel is not affected.

Why Azure Linux got the nod, and WSL2 didn’t

Microsoft’s advisory states that Azure Linux “includes this open-source library and is therefore potentially affected.” That’s an affirmative attestation, part of a transparency initiative that began in October 2025 with the rollout of machine-readable CSAF/VEX documents. Azure Linux—formerly known as CBL-Mariner and now the default container host for many Azure services—is the first Microsoft product to receive such automated attestations for open-source component vulnerabilities.

The advisory FAQ adds: “If impact to additional products is identified, we will update the CVE to reflect this.” For now, that leaves all other Microsoft products that ship a Linux kernel—including WSL2, certain Azure Marketplace images, and internal appliance kernels—without an official statement. Microsoft is not claiming they are safe; it is simply silent.

This does not mean WSL2 is automatically vulnerable, but it does mean the responsibility for verification shifts to the user or administrator. The WSL2 kernel, maintained in Microsoft’s public microsoft/WSL2-Linux-Kernel repository, is built from upstream Linux sources. Depending on the kernel version and configuration, it could include the ATM CLIP code.

What this means if you’re a WSL2 user

If you have WSL2 enabled on a Windows 10 or 11 machine, your system is running a Linux kernel under the hood. Microsoft distributes this kernel via Windows Update and the wsl --update command. The version you see when you run uname -r inside a WSL terminal is the key to assessing risk.

Many recent WSL2 kernels are based on the 6.6.x series. If your output shows a version below 6.6.99, and the CONFIGATM options are enabled, your kernel is theoretically vulnerable. A quick check can reveal whether the ATM CLIP code is present:

  • Run zgrep -i 'CONFIGATM' /proc/config.gz. If you see CONFIGATM=y or CONFIGATM=m, and CONFIGATMCLIP is similarly enabled, the vulnerable code is likely compiled in.
  • If the file /proc/config.gz doesn’t exist, check /boot/config-$(uname -r).

Microsoft has not published a formal attestation for WSL2, but based on prior kernel configurations, ATM support has often been enabled as a module. In that case, the module clip.ko may be present on disk and loadable—even if not currently loaded. You can look for it with find /lib/modules/$(uname -r) -name 'clip.ko'.

The practical risk of exploitation is low: an attacker would need local access to the WSL2 environment and a way to trigger the ATM code path, which is unlikely in typical desktop use. But for developers and IT pros who run containerized workloads or expose WSL2 instances to untrusted code, a kernel crash could be disruptive. The safer path is to update the WSL kernel to a patched version.

How to protect your systems: a practical guide

For Azure Linux customers

Microsoft has already made the fix available for Azure Linux. The MSRC advisory links to the security update guide with precise package versions. Cloud administrators should apply the latest kernel update or hotpatch from Microsoft’s repositories. If you use Azure Kubernetes Service (AKS) with Azure Linux node pools, reprovision your nodes with updated node images following Microsoft’s guidance.

For WSL2 users

  1. Update WSL2: Open PowerShell or Command Prompt and run wsl --update. This pulls the latest WSL2 kernel from Microsoft. After updating, verify the new kernel version inside WSL with uname -r and compare it to the fixed versions above.
  2. Check your kernel manually: If you’re using a custom WSL kernel configured via a .wslconfig file, you may need to rebuild or replace it with a patched source. The official microsoft/WSL2-Linux-Kernel repository includes the fix if you pull the latest commits.
  3. Mitigate without a reboot: If updating isn’t immediately possible and the clip module is present, you can blacklist it to prevent accidental loading. Create a file /etc/modprobe.d/blacklist-atm.conf with blacklist clip and run sudo modprobe -r clip if it’s currently loaded. This is a temporary workaround—the next WSL kernel update will supersede it.

For other Linux environments on Azure

If you run non-Azure-Linux VMs—Ubuntu, Debian, Red Hat, etc.—you are outside Microsoft’s direct attestation scope. Check your distribution’s security advisories: many vendors have already released patched kernels for this CVE. Use uname -r to compare against the fixed versions, and apply standard system updates.

Quick-reference commands

Run these inside your Linux environment (WSL, VM, or container host) to determine exposure:

# Check kernel version
uname -r

Look for ATM config (kernel config may be in different locations)

zgrep -i 'CONFIGATM' /proc/config.gz 2>/dev/null || grep -i 'CONFIG_ATM' /boot/config-$(uname -r)

Look for clip module on disk

find /lib/modules/$(uname -r) -name 'clip'

If the kernel version is older than the fixed release and ATM CLIP is enabled, you should prioritize an update.

The bigger picture: Microsoft’s transparency evolution

Microsoft’s decision to publish machine-readable VEX/CSAF documents marks a shift toward automated vulnerability lifecycle management. Starting with Azure Linux, the company intends to expand attestations to other products over time. For security teams, this means that for now, the absence of an MSRC statement for WSL2 or other Microsoft Linux offerings is not a warranty of safety—it simply indicates that those products have not yet completed the attestation process.

This is a pragmatic reality of modern software supply chains. As Microsoft increasingly embeds Linux kernels and open-source components across its ecosystem, the patchwork approach to vulnerability disclosure will gradually consolidate. The advisory for CVE-2025-38460 is a small but instructive step: it tells Azure Linux customers exactly where they stand, while reminding everyone else to stay vigilant.

What to watch next

The Linux kernel CVE announcement and upstream fixes leave no ambiguity about the technical scope. What remains uncertain is how quickly Microsoft will formally attest for WSL2 kernels, Azure Marketplace images, and other products. Until that happens, administrators of Microsoft-supplied Linux artifacts must continue to do their own kernel version hygiene—a task that requires little more than a few terminal commands.

Microsoft has committed to updating the CVE entry if additional impacted products are identified. If you rely on WSL2 for critical work, bookmark the MSRC advisory page and check back. In the meantime, a simple wsl --update might be all you need to close this niche but real kernel vulnerability.