On May 9, 2025, a Linux kernel maintainer patched a NULL pointer dereference in the cpupower benchmark tool, assigned CVE-2025-37841. Microsoft has confirmed that its Azure Linux distribution includes the vulnerable code and is affected—but the company's advisory stops short of clearing other Microsoft-shipped Linux artifacts, such as the Windows Subsystem for Linux 2 (WSL2) kernel or Azure virtual machine images. For defenders, that means the patch response window is wider than Azure Linux alone.

The Bug: A Simple Oversight with Local Consequences

The vulnerability lives in tools/power/cpupower/bench/parse.c, a source file for the cpupower utility—a userland tool for monitoring and managing CPU power states, not a kernel module. When memory allocation fails during a benchmarking routine, the code dereferences a null pointer without checking, causing a crash. A local user or script that invokes cpupower bench under low-memory conditions can trigger a denial of service.

The fix was a one-line change: adding a NULL check after the malloc call in prepare_default_config(). The Linux kernel’s stable maintainers backported the patch to all supported longterm branches, so any distribution shipping a recent kernel should include the fix. The Common Vulnerability Scoring System (CVSS) rates this as moderate—around 5.5—and attack complexity is low, but the exploitation vector is strictly local.

Where the Risk Hits Home: Azure, Your Workstation, and the Cloud

For Azure Linux administrators, the action is immediate. Microsoft’s advisory page explicitly states: “Azure Linux includes this open‑source library and is therefore potentially affected.” If you manage Azure Linux instances, apply the latest security updates that bundle the patched kernel-tools packages, or remove the cpupower utility if your workloads don’t need CPU benchmarking.

The oversight gap is broader. Microsoft’s advisory is a product‑scoped attestation—it means the company checked its Azure Linux image and found the code. It does not say other Microsoft‑curated images are safe. Several other Microsoft‑maintained Linux artifacts could plausibly ship the same code:

  • WSL2 kernels and distribution images. The WSL2 kernel source is publicly maintained on GitHub, and Microsoft builds and delivers the binary via Windows Update. While the default WSL distros do not typically install the linux-tools package, custom environments, developer scripts, or advanced users may pull in cpupower. Any WSL instance that runs cpupower bench is vulnerable until patched.
  • Azure Marketplace virtual machine images. These are often based on community or partner distributions that include the linux-tools metapackage. Unless the image builder explicitly excluded it, cpupower may be present.
  • Specialized Azure service images. Microsoft ships tuned kernels (like linux-azure) for specific VM performance profiles, and some niche appliance or telemetry images might embed benchmarking tools.
  • Developer and CI/CD containers. Build pipelines that use Microsoft‑provided base images for testing may inadvertently include cpupower, creating a local DoS surface on shared runner infrastructure.

Home users who run WSL2 for development or tinker with Linux on Windows are not at elevated risk unless they intentionally install and run cpupower. Still, it’s a quiet reminder that even a low‑severity bug in a tool can lurk on a system you think is secure.

The VEX Rollout: Why Microsoft Is Playing Catch-Up

This CVE highlights a milestone and a growing pain in Microsoft’s supply‑chain transparency efforts. In October 2025, the company began publishing Vulnerability Exploitability eXchange (VEX) and Common Security Advisory Framework (CSAF) documents, initially focusing on Azure Linux because it is the Linux distribution Microsoft curates end‑to‑end. The program is a direct response to the explosion of open‑source components in cloud and endpoint products, intended to give customers machine‑readable signals about which CVEs actually apply to their Microsoft‑owned artifacts.

Azure Linux was a logical starting point: it’s a single, well‑scoped product with a known package manifest. But Microsoft’s Linux footprint spans far more than one distro. The WSL2 kernel, the Azure‑tuned kernel modules deployed on some VM SKUs, and the base layers of many Azure PaaS offerings all embed open‑source software that must be inventoried and attested individually. The company’s MSRC advisory for CVE‑2025‑37841 includes the candid disclaimer: “If impact to additional products is identified, we will update the CVE to reflect this.” That sentence is both a promise of future transparency and an acknowledgment that the current attestation is incomplete.

For defenders, this means the absence of a VEX statement for, say, WSL2 is not a safe harbor. It means Microsoft has not yet checked. Treat unattested artifacts as “not yet assessed” rather than “not affected.”

Your Four-Point Checkup

To close the exposure gap, follow these steps. They’re ordered from broad inventory to precise action, and they work whether you manage a handful of Azure VMs or a fleet of developer workstations.

1. Inventory every Microsoft‑provided Linux image in your environment.
Create a list that includes Azure Linux instances, WSL2 installations on endpoints, Azure Marketplace VMs, AKS node images, and any custom images derived from Microsoft‑distributed kernels. For each, note the kernel version and any related tools packages.

2. Check for the cpupower binary.
On each image, run:

which cpupower

or, for package‑based checks:

dpkg -l | grep linux-tools
rpm -qa | grep cpupower

If the binary exists, record its version and the package source. On WSL instances, inspect all installed distros—wsl --list --verbose shows active ones; use wsl -d <Distro> -- which cpupower to test.

3. Map to the upstream fix.
The upstream commit (check stable kernel changelogs for tools/power/cpupower/bench/parse.c) was merged into longterm branches 5.10, 5.15, 6.1, 6.6, and newer. For Azure Linux, apply the latest updates from Microsoft’s repository. For WSL2, update the kernel via Windows Update or by manually fetching the latest from the WSL2 GitHub repo. For Marketplace images, run the distribution’s standard update procedures.

4. Remove or restrict cpupower where it’s unnecessary.
If your workloads never use CPU benchmarking, uninstall the package (apt purge linux-tools-* or equivalent) and remove the binary from build pipelines. This reduces attack surface. If you must keep the tool, limit execution permissions: chmod 750 /usr/bin/cpupower and ensure only trusted administrators can run it.

5. Use VEX as a starting point, not a security blanket.
Ingest Microsoft’s CSAF/VEX feeds into your vulnerability scanner if you rely on Azure products. They will light up with attestations for Azure Linux and, over time, other products. But until you see a “Not Affected” or “Fixed” entry for every Microsoft‑shipped Linux artifact you run, continue to perform the manual checks above.

What Comes Next

Microsoft’s VEX expansion roadmap is the key to closing this gap. The company has publicly committed to broadening attestations beyond Azure Linux, and it’s likely that WSL2 kernel images and popular Azure Marketplace images will be added to the CSAF feed in the coming months. Meanwhile, distribution maintainers will continue to backport the cpupower fix, and any kernel update you receive through normal channels should eradicate the bug.

For now, the takeaway is clear: CVE‑2025‑37841 is a minor code flaw with a major lesson about supply‑chain blind spots. Azure Linux is the poster child, but your WSL instance or cloud VM may be the next chip to fall. Inventory today, patch tomorrow, and keep an eye on Microsoft’s VEX feed—it’s your GPS through the open‑source patching jungle.