Microsoft has published an advisory for CVE-2025-37745, a Linux kernel bug that can cause system deadlocks, and has confirmed that its Azure Linux distribution is vulnerable. But the advisory stops short of assessing other Microsoft products that ship Linux kernels—such as the Windows Subsystem for Linux (WSL2) or various Marketplace images—leaving administrators to perform their own verification on those systems.

The Flaw: A Deadlock in the Linux Kernel’s Hibernate Path

At its core, CVE-2025-37745 is an availability issue in the Linux kernel’s power and hibernation subsystem. The bug, reported by the syzbot fuzzer, triggers a deadlock when a userspace process writes to /sys/module/hibernate/parameters/compressor while the system is transitioning into or out of hibernation. Under the hood, the handler for that sysfs file, hibernate_compressor_param_set, would attempt to acquire a lock (system_transition_mutex) that might already be held by the suspend path, while itself holding param_lock. The result: both threads wait forever, and the system hangs.

The upstream fix, now present in stable kernel branches, swaps the blocking mutex acquisition for a non-blocking mutex_trylock. If the lock can’t be grabbed immediately, the function returns -EBUSY, and the userspace write fails gracefully, preventing the deadlock. No privilege escalation or remote code execution is possible—this is purely a stability fix. The affected file is kernel/power/hibernate.c, and the relevant commits have been backported to multiple kernel versions.

Reading the Fine Print on Microsoft’s Advisory

Microsoft’s MSRC entry for CVE-2025-37745 contains a carefully worded statement: “Azure Linux includes this open‑source library and is therefore potentially affected.” That sentence is both an attestation and a boundary. It means Microsoft has run an inventory check on Azure Linux images and confirmed that they contain the vulnerable code. For customers running Azure Linux, this is an unambiguous, machine‑readable signal to patch. The advisory also notes that Microsoft started publishing CSAF/VEX attestations in October 2025, and that “if impact to additional products is identified, we will update the CVE to reflect this.”

The critical point—one that many readers miss—is that this attestation applies only to Azure Linux. It does not claim that no other Microsoft product carries the same bug. In fact, the advisory’s FAQ explicitly asks, “Is Azure Linux the only Microsoft product that includes this open‑source library and is therefore potentially affected by this vulnerability?” The answer, in essence, is: we’ve checked Azure Linux; we haven’t checked everything else yet. This is a phased rollout of vulnerability attestation, not a comprehensive assessment of all Microsoft Linux artifacts.

Which Other Microsoft Systems Might Be Vulnerable?

If Azure Linux is affected, it’s reasonable to ask: what else in the Microsoft ecosystem ships a Linux kernel that could include the unpatched hibernation code? The list includes, but isn’t limited to:

  • Windows Subsystem for Linux (WSL2): WSL2 runs a Microsoft‑packaged Linux kernel. The default kernel image and its configuration are public, and depending on the kernel version and build options, it could contain the vulnerable hibernate.c code. Many users run the default Microsoft kernel, while others compile custom ones.
  • CBL‑Mariner and other internal images: Azure Linux itself is based on CBL‑Mariner. Microsoft uses this lineage for various base images in Azure infrastructure and for internal appliances. Some of these may share the same kernel tree and, if not updated, remain exposed.
  • Marketplace VM images and partner appliances: A plethora of Azure Marketplace offerings embed custom or vendor‑maintained Linux kernels. These are not automatically covered by Microsoft’s VEX for Azure Linux, and the vendor’s own advisory may be the primary source of truth.
  • Custom or static kernel builds: Any container host, IoT device, or specialized VM that includes a kernel built from vulnerable upstream sources is a carrier until the binary is replaced with a patched version.

In each case, the absence of a Microsoft VEX attestation means “not yet attested,” not “proven safe.” Admins must verify these systems independently.

How to Check If Your Systems Are at Risk

Verification is straightforward if you know where to look. Use these steps to assess exposure across your Microsoft Linux footprint:

  1. On physical hosts or VMs:
    - Run uname -r to get the kernel version.
    - Check /boot/config-$(uname -r) or /proc/config.gz for CONFIG_HIBERNATION. If it’s set, the hibernation code is compiled in.
    - Search for the fix commit in your kernel’s changelog. If the kernel was built before the repair, you’re vulnerable.

  2. For WSL2:
    - Check the WSL kernel version with wsl cat /proc/version.
    - Compare against Microsoft’s published WSL2 kernel releases. If the version predates the fix, update via wsl --update or by installing a newer kernel package.

  3. For Azure and Marketplace images:
    - Use Azure’s image inventory APIs or other SBOM tools to identify the kernel package.
    - For Marketplace images, consult the ISV’s security advisory, as Microsoft’s VEX won’t cover those.

  4. Monitor for symptoms:
    - Kernel oops or lockup traces mentioning system_transition_mutex and param_lock are red flags. Audit writes to /sys/module/hibernate/parameters/compressor from untrusted processes.

What to Do Right Now

Patch Azure Linux immediately. Microsoft has said Azure Linux is affected, so treat that as a high‑priority update. Update your Azure Linux VMs and container hosts to the latest kernel package offered through the distro’s channels.

For all other Microsoft‑supplied Linux artifacts:

  • WSL2 users: If not on the latest kernel, run wsl --update. For custom kernels, recompile with the upstream fix.
  • CBL‑Mariner‑based or custom images: Rebuild from updated sources or apply the available kernel upgrade.
  • Third‑party Marketplace images: Contact the vendor for a patched image or update the kernel yourself if you have root access.

Mitigations if patching is delayed:

  • Restrict write access to /sys/module/hibernate/parameters/compressor. Use file permissions, seccomp, or LSM rules to block writes from unprivileged processes.
  • Avoid triggering hibernation or suspend transitions while local users or services might be writing to that sysfs entry.
  • Set up monitoring for kernel deadlock traces and automate a reboot if a hang is detected, to restore availability quickly.

The Bigger Picture: A Phased Rollout with Room for Improvement

Microsoft’s move toward machine‑readable VEX attestations is a net positive for vulnerability management. For Azure Linux customers, the advisory provides a clear, automatable signal that drastically reduces triage time. However, the phased approach has a notable downside: everyone else is left to manually fill the attestation gap.

This is part of an industry‑wide shift, but it also highlights a recurring tension. Vendors can’t attest to every artifact overnight, so they start with flagship products. The risk is that some administrators will misinterpret the advisory as covering all Microsoft Linux offerings, when in reality, WSL2, various Marketplace VMs, and custom images fall outside the current attestation scope. Until Microsoft expands its VEX coverage, the burden of verification for those products shifts to the user.

It’s a useful step forward, but for now, it’s an incomplete one. Operationally, the rule is simple: if Microsoft hasn’t said “affected” for a specific product, assume no one has checked and do the work yourself.

Outlook

Microsoft will likely extend VEX attestations to additional Linux artifacts over time. The MSRC statement that it will “update the CVE” if other products are identified as carriers suggests inventory checks are ongoing. In the meantime, watch for updates to the CVE entry and any associated security advisories. The broader lesson: as vendor attestations become more common, the absence of a VEX record will increasingly be a signal that manual verification is needed—not that a system is safe. For now, patch what you can, verify what you must, and keep an eye on Microsoft’s CSAF feed.