Microsoft has issued a security advisory confirming that Azure Linux contains a kernel vulnerability (CVE-2025-37878) that can trigger system warnings, crashes, or instability through the performance monitoring subsystem. The company has not ruled out that other Microsoft-distributed Linux kernels — including those in WSL2, AKS, and marketplace images — may be affected. While Azure Linux users must patch immediately, the advisory signals that IT teams must verify all their Microsoft-sourced Linux workloads, not just the one named product.

What the Vulnerability Actually Is

CVE-2025-37878 is a flaw in the Linux kernel’s perf subsystem, specifically in the way partially initialized performance events are torn down. The bug can cause a WARN_ON(!ctx) condition when a performance event structure is freed without a proper context pointer, leading to kernel warning messages or, in certain configurations, system crashes. The perf subsystem handles performance counters, sampling, and tracing, so any software that heavily uses these features — profiling tools, monitoring agents, or forensic collectors — could trigger the bug. The fix adds a defensive check to avoid the null pointer dereference during event cleanup.

Microsoft’s advisory, published on the MSRC update guide, states: “Azure Linux includes this open‑source library and is therefore potentially affected.” It does not claim that Azure Linux is the only Microsoft product with the vulnerable code; it merely confirms one product after inspection. Microsoft has committed to updating the CVE record and its machine-readable CSAF/VEX attestations if additional products are later found to include the component.

What This Means for Azure Linux Users

If you run Azure Linux virtual machines, either directly or as part of Azure Kubernetes Service node pools, you are confirmed to have this vulnerability. The risk is primarily operational: unexpected kernel warnings (dmesg or journalctl) can clutter logs and, in the worst case, cause a kernel oops or panic that crashes the VM. While the bug is not known to enable remote code execution, it is a reliability and denial-of-service concern, especially in production environments where stability is critical. Microsoft has likely prepared a patched kernel; you should apply it as soon as it is released and reboot your hosts.

What This Means for Other Microsoft Linux Workloads

This is where the advisory becomes tricky. Many enterprises use Microsoft-provided or -signed Linux artifacts beyond Azure Linux: WSL2 kernels on Windows 11/10, Azure Marketplace images (some based on older or customized kernels), container host images, and internal platform builds. Because the vulnerable perf code is part of the upstream Linux kernel, any Microsoft-distributed kernel built with perf support could theoretically include the bug. Until Microsoft individually verifies and attests each artifact, you cannot assume safety.

For example, a WSL2 kernel on your developer workstation might include the same code path. If you run performance analysis inside WSL2, you could trigger the warning or instability. While WSL2 crashes are less impactful than a production server, they can disrupt work and indicate a broader exposure. AKS node images based on Ubuntu or other non-Azure-Linux kernels might or might not be affected — it depends on whether the kernel was built from a tree that included the bug. Microsoft’s promise to update the CVE when new products are identified is a good sign, but security teams must do their own inventory in the interim.

How We Got Here: The Complexities of Open-Source Components in Proprietary Products

This situation highlights the challenges of tracking open-source vulnerabilities across a large software portfolio. Microsoft, like many vendors, ships numerous products that incorporate Linux kernels in various forms. In October 2025, Microsoft began publishing CSAF/VEX (Common Security Advisory Framework / Vulnerability Exploitability eXchange) attestations to provide machine-readable statements about which products are affected by which CVEs. This move aimed to increase transparency for customers managing open-source risks.

For CVE-2025-37878, Microsoft’s single-product attestation for Azure Linux demonstrates the initial scope of their inventory process. They looked at Azure Linux, found the vulnerable library, and declared it affected. But a comprehensive inventory of all possible carriers is a massive engineering effort. Other products might use the same upstream code but with different configurations, build flags, or namespacing — making automated detection difficult. The result is a partial picture that puts the onus on customers to fill in the gaps.

What You Should Do Now: A Practical Action Plan

Step 1: Patch Azure Linux Without Delay

If you manage Azure Linux VMs or AKS node pools running Azure Linux, check for Microsoft’s updated kernel package. For Azure Linux, you can use the standard package manager (e.g., sudo apt update && sudo apt upgrade on Debian-based Azure Linux) or follow the vendor’s security advisory. Reboot your nodes as needed. For AKS, you may need to upgrade your node image to a patched version; consult the AKS release notes for the precise version.

Step 2: Inventory All Microsoft-Distributed Linux Artifacts

List every place you run a Linux kernel that Microsoft provides or signs:
- WSL2 instances on Windows machines. Check your kernel version: run uname -r inside WSL2. Note that WSL2 kernels are delivered via Windows Update, so ensure you have the latest updates. Microsoft has not yet confirmed or denied WSL2 exposure; if you depend on WSL2 for critical workloads, consider limiting perf usage or monitoring logs.
- Azure Marketplace images. Even if they are named “Ubuntu” or “CentOS,” Microsoft may host or manage them. Check the publisher: if it’s Microsoft, it’s a Microsoft-distributed image. Pull the kernel version and config from running VMs.
- AKS node images that are not Azure Linux. AKS supports multiple OS options; if you use Ubuntu or others, verify the kernel version and check if the node image has been patched by the image maintainer.
- Azure container hosts or platform images used for services like Azure Container Instances or Azure Functions. These are largely managed, but you should be aware of potential exposure.
- Any custom images you built using Microsoft’s base images or kernel packages.

Step 3: Check CSAF/VEX Attestations

Microsoft’s CVE page (MSRC Update Guide) will be updated as they identify more products. You can also request the CSAF document programmatically. If you use a vulnerability scanner that ingests CSAF, ensure it’s fetching the latest version. For artifacts not yet attested, you’ll need to rely on kernel version comparison.

Step 4: Verify Kernel Exposure Manually

For each artifact, determine if the kernel contains the vulnerable code. The bug is in the perf subsystem, specifically in the file kernel/events/core.c in the function __free_event. To confirm, you need the exact kernel source tree commit. If you have access to the kernel config (zcat /proc/config.gz or /boot/config-*), look for CONFIG_PERF_EVENTS=y. Most general-purpose kernels enable perf. If the kernel version is one that includes the upstream commit introducing the bug (and hasn’t backported the fix), it’s likely vulnerable. Since Microsoft hasn’t published commit hashes for all images, this is tricky. You can compare your kernel version string with known vulnerable versions; however, version strings alone are insufficient because vendors often backport patches. A more reliable method is to check if the specific fix has been applied. If you cannot determine, assume vulnerable until Microsoft clarifies.

Step 5: Implement Mitigations if Patching Is Delayed

If you can’t patch immediately (e.g., for a managed service that hasn’t released a fix), reduce the attack surface for the perf subsystem:
- Increase perf_event_paranoid: echo 2 > /proc/sys/kernel/perf_event_paranoid (or set via sysctl). This restricts access to performance events to root or prevents unprivileged use entirely.
- In container environments, drop the CAP_PERFMON and CAP_SYS_ADMIN capabilities, or use seccomp profiles to block the perf_event_open syscall.
- Monitor kernel logs for WARN_ON traces. Set up alerts for WARN_ON in dmesg that mention perf or __free_event. Centralized logging systems like Azure Monitor, Splunk, or ELK can detect these patterns.

Step 6: Monitor and Report

Keep an eye on Microsoft’s CVE page and your vulnerability management platform. If you discover that a Microsoft artifact not listed in the advisory is vulnerable, report it to Microsoft and request an updated attestation. This helps the community.

Outlook: Better Attestations Are Coming, but Vigilance Remains Essential

Microsoft’s CSAF/VEX initiative is a step toward more transparent vulnerability management, but CVE-2025-37878 shows that a single attestation is not a comprehensive shield. As Microsoft expands its inventory processes, we can expect more products to be explicitly covered in future CVEs. In the meantime, IT teams should adopt a defensive posture: treat any Microsoft Linux kernel as potentially vulnerable until proven otherwise, and build verification into regular patch cycles. The perf subsystem bug itself is relatively low severity compared to remote exploits, but it underscores the importance of meticulous supply chain security. For now, patch Azure Linux, inventory your estate, and keep watching for updates.