The short answer is: No — Azure Linux is not necessarily the only Microsoft product that could include the vulnerable open‑source code, but it is the only Microsoft product Microsoft has publicly attested (so far) to contain the specific cpupower/bench component covered by CVE‑2025‑37841. Microsoft’s public wording is an authoritative, product‑scoped attestation for Azure Linux; it is not a categorical exclusion of other Microsoft images, kernels, or artifacts. //archive.vn/2025.12.04-184202/https%3A/msrc.microsoft.com/update-guide/vulnerability/CVE-2025-39810)
On May 9, 2025 the Linux project closed a small but real robustness bug tracked as CVE‑2025‑37841: a NULL‑pointer dereference in the cpupower benchmarking code path. The fix adds a simple NULL check after a malloc call in tools/power/cpupower/bench/parse.c to avoid dereferencing a NULL config pointer when memory allocation fails. The change was merged into the kernel trees and staged for stable backports.
The vulnerability is a local issue (attack vector: local), with denial‑of‑service impact if an unprivileged local user or utility triggers cpupower bench under low‑memory conditions. Public aggregators list the issue with a moderate impact classification (CVSS v3 ~5.5) and note the availability of upstream and distribution patches.
Microsoft’s Security Response Center (MSRC) pages for a number of Linux CVEs — including the sequence of kernel and tools fixes from 2025 — include the repeated FAQ language used by the company’s VEX/CSAF rollout: “Azure Linux includes this open‑source library and is therefore potentially affected. … If impact to additional products is identified, we will update the CVE to reflect this.” That phrasing is accurate for the product Microsoft has inspected and is part of a deliberate, phased VEX attestation program that began with Azure Linux.
However this product‑level attestation is not the same as a guarantee that no other Microsoft product ships the same vulnerable component. That nuance has been repeatedly explained in vendor‑mapping coverage and in the internal advisories we reviewed: the MSRC statement is a confirmed mapping for Azure Linux, not a proof of non‑inclusion for every other Microsoft artifact. Treat Microsoft’s Azure Linux attestation as an authoritative confirmation for that specific product family; treat the absence of attestations for anything else as “not yet checked” rather than “not affected.”
Why: cpupower is a common development/diagnostic utility drawn from the kernel tools tree. Microsoft produces and ships Linux kernel artifacts in multiple places; different product lines and images may include the tools package or kernel‑derived utilities in the image or as part of a support package. The most obvious candidates to verify are:
Microsoft’s VEX/CSAF initiative is a clear step toward better supply‑chain clarity and faster customer decision making. That transparency is a strength — but product‑scoped attestations require precise reading and downstream verification. For CVE‑2025‑37841 the evidence is clear: Azure Linux is a confirmed, attested carrier; other Microsoft artifacts are plausible carriers and must be inspected and patched where they include the cpupower bench tool or equivalent packaging. Prioritize inventory and remediation, use Microsoft’s machine‑readable attestations as a starting point, and assume that any Microsoft artifact that runs or packages a Linux kernel or tools should be verified until it is explicitly attested as Not Affected or Fixed.
Conclusion: Azure Linux is the only Microsoft product Microsoft has publicly attested, but it is not — by logical necessity — the only Microsoft product that could include the vulnerable cpupower/bench code. Operators should act accordingly: verify, patch, remove where unnecessary, and use VEX/CSAF as a helpful but not exclusive source of truth.
Source: MSRC Security Update Guide - Microsoft Security Response Center
Background / Overview
On May 9, 2025 the Linux project closed a small but real robustness bug tracked as CVE‑2025‑37841: a NULL‑pointer dereference in the cpupower benchmarking code path. The fix adds a simple NULL check after a malloc call in tools/power/cpupower/bench/parse.c to avoid dereferencing a NULL config pointer when memory allocation fails. The change was merged into the kernel trees and staged for stable backports.The vulnerability is a local issue (attack vector: local), with denial‑of‑service impact if an unprivileged local user or utility triggers cpupower bench under low‑memory conditions. Public aggregators list the issue with a moderate impact classification (CVSS v3 ~5.5) and note the availability of upstream and distribution patches.
Microsoft’s Security Response Center (MSRC) pages for a number of Linux CVEs — including the sequence of kernel and tools fixes from 2025 — include the repeated FAQ language used by the company’s VEX/CSAF rollout: “Azure Linux includes this open‑source library and is therefore potentially affected. … If impact to additional products is identified, we will update the CVE to reflect this.” That phrasing is accurate for the product Microsoft has inspected and is part of a deliberate, phased VEX attestation program that began with Azure Linux.
What exactly is affected (technical details)
The vulnerable component
- The problematic code lives in the cpupower bench tool under the kernel source's tools tree: tools/power/cpupower/bench/parse.c. The change adds a defensive NULL check after malloc in prepare_default_config(), avoiding use of the uninitialized config pointer.
Why this matters
- Because this code path is in a utility under tools/power, it is a userland program compiled from the kernel source tree (linux-tools / cpupower), not a kernel runtime subsystem. That distinction matters operationally: the vulnerability is triggered by running the cpupower bench executable, not by a remote network packet to the kernel. As such it is a local robustness issue (denial of service) rather than a remote kernel‑level compromise. Several vendor advisories and stable‑commit lists tracked the patch and backported it to the stable series.
Exploitability and practical exposure
- Exploitation requires local execution of the specific bench tool or a scenario where an untrusted user can cause that binary to run. On many systems cpupower is provided as part of a larger tools package and is not installed by default on all images. For images and appliances that do ship cpupower or include the linux-tools packages, local adversaries could trigger the bug to cause a DoS or crash. Public vulnerability databases and distribution advisories classify the exploitability as low‑complexity but local.
Reading Microsoft’s wording: “Azure Linux includes this open‑source library …” — what it does and does not say
Microsoft’s MSRC messaging and its newer VEX/CSAF attestations are intentionally precise: they declare which Microsoft product artifacts have been inventory‑checked and found to include a given upstream component, and they promise to expand attestations over time. Starting the VEX rollout with Azure Linux made operational sense — Azure Linux (the distribution lineage Microsoft curates) is a single catalog of artifacts easier to scan and attest at scale. Microsoft’s blog describing the VEX program explains the phased approach and why the company began with Azure Linux.However this product‑level attestation is not the same as a guarantee that no other Microsoft product ships the same vulnerable component. That nuance has been repeatedly explained in vendor‑mapping coverage and in the internal advisories we reviewed: the MSRC statement is a confirmed mapping for Azure Linux, not a proof of non‑inclusion for every other Microsoft artifact. Treat Microsoft’s Azure Linux attestation as an authoritative confirmation for that specific product family; treat the absence of attestations for anything else as “not yet checked” rather than “not affected.”
Could other Microsoft products include cpupower/bench?
Short answer: yes — technically plausible, and several Microsoft‑distributed artifacts are plausible carriers until proven otherwise.Why: cpupower is a common development/diagnostic utility drawn from the kernel tools tree. Microsoft produces and ships Linux kernel artifacts in multiple places; different product lines and images may include the tools package or kernel‑derived utilities in the image or as part of a support package. The most obvious candidates to verify are:
- Windows Subsystem for Linux (WSL / WSL2) kernels and images. Microsoft publishes the WSL2 kernel source tree on GitHub and builds a WSL‑specific kernel binary that is delivered and serviced via Windows Update — that kernel tree (and the WSL packaging) carious tools and drivers when Microsoft chooses to ship them. The published WSL2 source repository is an open, easily inspected artifact that demonstrates Microsoft maintains its own kernel build pipelines.
- Azure VM images, Marketplace images, and other Azure‑curated images. Azure Marketplace images and many curated VM images are built from Linux distributions and often include distribution tools (linux‑to, etc.). Microsoft’s initial VEX attestation focused on Azure Linux images because those are Microsoft‑curated; the same logic (images built from distro packages) means other Marketplace or Azure images might carry cpupower depending on how they were built.
- “linux‑azure” or Azure‑tuned kernel artifacts used by specific VM SKUs, AKS nodes, or specialized services. Microsoft maintains a variety of kernel build pipelines and image artifacts for cloud services; each build pipeline is an inventory item that must be checked independently. A Microsoft statement that Azure Linux includes an upstream component means Microsoft checked that particular product family — it does not automatically prove all kernel artifacts and images are unaffected.
- Other internal Microsoft appliances and developer images that are built from upstream kernels or ship linux tools as part of their image (for example, specialized telemetry or benchmarking appliances). Those artifacts are less public, and absence of an explicit VEX attestation leaves them unverified.
What defenders need to do now (practical, prioritized steps)
Below is a sequence of investigative and remediation actions security teams should follow. These are practical, ordered steps designed to give you a repeatable method for mapping exposure across both on‑prem and cloud assets.- Inventory images and kernels
- Identify which images you run that are Microsoft‑provided (Azure Marketplace images, Azure Linux images, WSL2 kernels provided to endpoints, AKS node images).
- For each image, record the kernel version and installed packages (dpkg -l / rpm -qa) or the image manifest. Look specifically for packages named cpupower, linux‑tools, or distro packages that ship tools/power utilities.
- Check for the cpupower binary or the tools tree presence
- Search images and VMs for a cpupower/bench binary:
which cpupowerorfind / -name cpupower -type f. - If you use image build pipelines, inspect the build manifests for inclusion of linux‑tools or cpupower packages.
- Map kernel and package versions to the upstream fix
- The upstream patch was merged and backported to stable branches; match your kernel/package version to vendor advisories and the upstream commit. Use the kernel commit identifiers in the stable commit logs and distribution advisories as the canonical mapping.
- Patch or remove
- If cpupower is present, update the distribution package to an upstream‑patched version (apply distro security updates).
- If cpupower is not needed on production images, consider removing it from image builds and artifact manifests to reduce attack surface.
- Restrict local access
- Because the vulnerability requires local execution, restrict who can execute the cpupower binary (file permissions, sudo policies, container runtime controls). Limit accounts and automation that can run benchmarking tools.
- Use Microsoft’s CSAF/VEX attestations as a starting point — but verify
- Ingest Microsoft’s VEX/CSAF feeds if you rely on Microsoft artifacts. They offer machine‑readable attestations for Azure Linux (and a roadmap to expand). But treat the absence of a VEX entry for another Microsoft product as “not yet attested,” and follow the inventory steps above.
Why Microsoft’s approach is both a strength and a risk
Strengths
- Microsoft’s move to publish CSAF/VEX attestations and to start with Azure Linux represents a material improvement in supply‑chain transparency. Customers can automate impact triage and reduce noisy investigations for products Microsoft has already attested. The MSRC blog explains the VEX rollout and why starting with one product family is practical and measurable.
- The product‑scoped attestations are machine‑actionable and help security teams prioritize patching and threat modelling across hybrid environments.
Risks and potential misinterpretations
- Some readers — and some automated scanners — can misinterpret the plain English line “Azure Linux includes this open‑source library and is therefore potentially affected” as a global statement that only Azure Linux could be affected. That interpretation is incorrect. Microsoft’s wording describes the results of an inventory for a specific product; it does not exclude other artifacts. Multiple advisories and analysis threads have emphasized this distinction: an attestation ≠ exclusivity.
- The phased attestation approach leaves a temporary window where other Microsoft art Marketplace images, VM images) may be un‑attested but still carry the vulnerable code. If operations teams assume the MSRC page implies global safety, they risk leaving unpatched artifacts in service.
Specific considerations for WSL, Azure VMs, and developer machines
- WSL2 uses a Microsoft‑built Linux kernel; Microsoft publishes that kernel’s source (the WSL2‑Linux‑Kernel GitHub repo). Because Microsoft builds and ships its own kernel binaries and occasionally ships or supports additional tools inside WSL images, WSL instances deserve explicit verification in environments where endpoint risk matters. Inspect the WSL kernel version/service channel and any linux‑tools packages installed inside WSL images.
- Azure Marketplace and custom VM images: these are often assembled from upstream distro images and may include extra packages. Image manifests and build recipes are the right place to look — not the assumption that a single MSRC attestation covers all Azure‑branded artifacts.
- Developer and CI/CD build runners: CI images used by developers and internal build infrastructure sometimes include benchmarking tools for telemetry. Those build images should be included in your inventory sweep.
Where the public evidence points (summary of verification)
- Upstream patch and commit history: the cpupower bench patch was submitted, reviewed, and merged into upstream and stable trees; archives like Patchew and stable‑commit lists show the exact change adding a malloc NULL check.
- Public CVE and aggregator entries: NVD and other trackers list CVE‑2025‑37841 with the standard vulnerability description and point to the upstream fixes. Distribution advisories (Debian, SUSE, Red Hat family feeds) created matching advisories and backports.
- Microsoft’s public VEX/CSAF rollout: Microsoft documented VEX adoption and began publishing attestations for Azure Linux; its MSRC pages include the same FAQ wording for a number of Linux CVEs, including the explanation about expanding VEX/CSAF mappings as more artifacts are checked. That is Microsoft’s declared process and timeline for disclosure.
- Analysis and community commentary: independent security posts and vendor advisories reiterate the operational nuance — Azure Linux is a confirmed carrier because Microsoft checked it; other Microsoft artifacts must be verified separately. These independent analyses mirror the approach and caveats described above.
Final analysis and recommended posture for teams that consume Microsoft images
- Treat Microsoft’s Azure Linux attestation as authoritative for the Azure Linux product family: if you run Azure Linux images, act immediately to apply vendor updates or remove the offending utility from hosts that do not need it.
- Do not assume other Microsoft products are unaffected simply because they are not in the VEX manifest yet. Inventory, scan, and validate any Microsoft‑distributed kernel images/VM images/WSL kernels you run. Evidence from public Microsoft repositories and the reality of multiple kernel artifacts under Microsoft’s control make other artifacts plausible carriers.
- Use Microsoft’s CSAF/VEX feeds to automate triage where possible, but combine those feeds with local image manifest checks and package scans. A defense in depth approach—patch, remove, restrict execution—is the safest path.
- If you need a prioritized, repeatable checklist to hand to operations teams, use the numbered investigative steps earlier in this article and treat local execution constraints (who can run cpupower, CI images, developer laptops) as the highest immediate risk surface because the vulnerability is locally triggered.
Microsoft’s VEX/CSAF initiative is a clear step toward better supply‑chain clarity and faster customer decision making. That transparency is a strength — but product‑scoped attestations require precise reading and downstream verification. For CVE‑2025‑37841 the evidence is clear: Azure Linux is a confirmed, attested carrier; other Microsoft artifacts are plausible carriers and must be inspected and patched where they include the cpupower bench tool or equivalent packaging. Prioritize inventory and remediation, use Microsoft’s machine‑readable attestations as a starting point, and assume that any Microsoft artifact that runs or packages a Linux kernel or tools should be verified until it is explicitly attested as Not Affected or Fixed.
Conclusion: Azure Linux is the only Microsoft product Microsoft has publicly attested, but it is not — by logical necessity — the only Microsoft product that could include the vulnerable cpupower/bench code. Operators should act accordingly: verify, patch, remove where unnecessary, and use VEX/CSAF as a helpful but not exclusive source of truth.
Source: MSRC Security Update Guide - Microsoft Security Response Center
