Microsoft has confirmed that a serious kernel vulnerability—dubbed CVE-2025-38112—puts its Azure Linux distribution at risk of system crashes, but has not publicly cleared other Microsoft products that use Linux code, including Windows Subsystem for Linux 2 (WSL2). The advisory, posted on Microsoft's Security Response Center, urges immediate patching for Azure Linux while offering only a conditional ‘we’ll update the CVE’ for anything else, leaving administrators and developers to sort out their own exposure.

What the Vulnerability Actually Does

At its core, CVE-2025-38112 is a race condition in the Linux kernel’s networking stack. The flaw lives in a function called sk_is_readable(), which checks whether a socket is ready to be read. In certain scenarios—particularly when sockets are managed through sockmap operations—a function pointer (sk->sk_prot->sock_is_readable) can be verified as non-null at the moment of inspection but then, in the split-second before it is used, be changed to null by another thread or process. That time-of-check to time-of-use (TOCTOU) flaw can cause the kernel to dereference a null pointer and crash.

The result is a classic denial-of-service (DoS) condition: a kernel panic or oops that kills the host. The attack requires the ability to create and manipulate socket lifecycles, which typically means local access. That makes remote exploitation unlikely, but in cloud and multi-tenant environments—where an unprivileged user in one virtual machine or container could trigger a host kernel crash—it remains a significant operational risk.

According to Microsoft’s advisory and upstream Linux security announcements, the vulnerable code was introduced in a series of commits a few kernel versions back. The kernel community has since merged fixes into stable releases, and distributions are racing to backport them.

Who’s Confirmed Affected—And Who Isn’t

Microsoft has publicly attested that Azure Linux includes the vulnerable upstream code. That attestation, built on its CSAF/VEX (Common Security Advisory Framework / Vulnerability Exploitability eXchange) program launched in October 2025, means customers can programmatically mark Azure Linux images as affected and trigger automated patching workflows. It is the only Microsoft product explicitly named in the advisory.

But the advisory also says: “If impact to additional products is identified, we will update the CVE to reflect this.” That statement is intentionally narrow. A lack of attestation does not equate to a clean bill of health. Microsoft ships Linux kernel binaries in many other forms:

  • The WSL2 kernel, delivered via Windows Update and used on millions of developer machines.
  • Azure Marketplace virtual machine images that bundle linux-azure kernels or other distro-specific kernels.
  • Azure Kubernetes Service (AKS) node images that rely on Microsoft-curated kernel packages.

Whether any of these contain the vulnerable code depends on the exact kernel version and build configuration. Because Microsoft has not yet issued CSAF/VEX entries for them, IT teams are left to perform their own artifact inspection.

For Different Audiences: What’s the Real Risk?

Azure Linux Admins
You have a confirmed hit. Patch immediately. The fix is available through the standard Azure Linux update channels. Apply it and reboot hosts as soon as possible—especially in shared-tenancy or production scenarios where a host crash would ripple across workloads.

WSL2 Users and Developers
The risk profile is lower for single-user developer machines because triggering the bug requires local code execution. But if you use WSL2 for CI/CD pipelines, run untrusted code in a WSL2 instance, or share the machine with other users, a kernel panic could disrupt your work. Check your WSL2 kernel version by running uname -r inside a WSL2 terminal. Compare it against the upstream kernel’s fixed versions (the kernel community has published detailed commit ranges). Microsoft’s own WSL2 kernel source repository is tagged by version, so you can also check there. If you run a custom kernel, rebuild it against a patched upstream baseline. For most users, the WSL2 kernel updates automatically with Windows Update—ensure you’re on the latest version.

Cloud and Virtualization Admins
If you manage Azure VM images beyond Azure Linux, check whether your images use a kernel version within the affected range. This includes Ubuntu, Debian, or other images that bundle Microsoft-tuned kernels. Reach out to your distribution vendor for confirmation and patches. For AKS node pools, verify the node image version against patched releases. If you can’t patch immediately, consider applying restrictive seccomp or AppArmor profiles to workloads that might manipulate socket internals, and isolate multi-tenant applications in stronger sandboxing boundaries.

IT Security Teams
Inventory every Microsoft-supplied Linux kernel artifact in your environment. Adopt tooling that ingests CSAF/VEX feeds so you can automate exposure checks when Microsoft does publish attestations. In the meantime, use kernel version mapping against known affected ranges. Remember: until Microsoft issues a VEX entry for an artifact, that artifact should be treated as potentially vulnerable.

How We Got Here: The Growing Linux-in-Windows Footprint

Microsoft’s embrace of Linux over the past decade has been remarkable. WSL brought a full Linux kernel into Windows; Azure Linux became Microsoft’s own lightweight distribution for cloud workloads; and Azure’s infrastructure runs countless Linux virtual machines and containers. This convergence means that a single upstream kernel bug can touch a surprisingly broad set of Microsoft products.

In October 2025, Microsoft began publishing machine-readable CSAF/VEX data to improve transparency around open-source vulnerabilities in its products. The initiative is a boon for defenders: when Microsoft attests that a particular product version contains a CVE, you can automate the remediation pipeline without manual research. But as this CVE demonstrates, coverage isn’t yet universal. The advisory’s careful wording reflects that attestation is a per-product workflow, and Microsoft is still rolling it out across its portfolio.

Historically, WSL2 kernels and Azure images have tracked upstream Linux stable releases, sometimes lagging by a few weeks. Kernel vulnerabilities that affect these codebases aren’t new—previous CVEs in the kernel’s networking or filesystem code have forced similar triage scrambles. CVE-2025-38112 is a reminder that shared code means shared risk, and that even a company as large as Microsoft can’t immediately atomically attest every binary it ships.

What to Do Now: A Practical Action Plan

  1. Patch Azure Linux Immediately
    Run the vendor update command for your Azure Linux instances (tdnf update or the equivalent) and reboot. Confirm the new kernel version is active.

  2. Check WSL2 Kernel Versions
    Run uname -r in WSL2. If the kernel version is older than a patched release (the upstream announcements list fixed versions for the 5.15, 6.1, 6.6, and later stable trees), trigger a Windows Update check to receive the latest WSL2 kernel. For custom kernels, rebuild using a patched upstream tag.

  3. Audit Other Azure Images
    For any Azure VM or AKS node not running Azure Linux, consult the OEM or community distro’s security tracker. If you built custom images, pull the kernel version and compare it against the upstream fix commits.

  4. Apply Interim Mitigations Where Patching Is Blocked
    If you cannot reboot a critical system immediately, reduce the attack surface: remove unprivileged user access, block tools that manipulate sockmaps (e.g., by restricting bpf() syscalls), and monitor kernel logs for panics or oops messages that could indicate exploitation attempts.

  5. Improve Long-Term Inventory Hygiene
    Start ingesting CSAF/VEX data from Microsoft and other vendors. Use SBOM (Software Bill of Materials) tools to track kernel versions across your fleet. When the next CVE hits, you’ll be able to answer “are we affected?” in minutes, not days.

What Comes Next

Microsoft will almost certainly expand its CSAF/VEX coverage in the coming months, and the company may issue specific guidance for WSL2 once its internal analysis is complete. In the meantime, the uncertainty around CVE-2025-38112 underscores a broader lesson: supply-chain transparency is powerful, but it works best when coverage is complete. Until then, defenders must combine vendor attestations with their own verification.

Keep an eye on your Windows Update history and the WSL2 GitHub repository—patches often land silently. And if you run anything that smells like Linux in your Microsoft environment, now is a good time to make sure you know exactly which kernel version you’re booting.