Azure Linux and WSL at Risk: CVE-2025-37936 Kernel PEBS Bug

Microsoft’s public advisory for CVE-2025-37936 correctly identifies a flaw in the Linux kernel’s perf/x86/intel KVM code that can allow a guest to be run with PEBS (Precise Event-Based Sampling) enabled when the guest itself did not request it — and Microsoft’s published inventory currently lists Azure Linux as the Microsoft product that has been confirmed to include the upstream library/component and therefore is potentially affected. However, that product-level attestation is a conservative, scoped statement of what Microsoft has verified so far; it is not a technical guarantee that no other Microsoft product ships the same vulnerable code. Any Microsoft artifact that ships a Linux kernel (or kernel modules) built from the vulnerable commit range and with the relevant kernel config options enabled could be in scope until proven patched or shown not to include the code.

---

Background / Overview​

CVE-2025-37936 is a kernel-level vulnerability in the perf/x86/intel KVM path. At a high level:

• What the bug does. When KVM constructs the value to load into the MSR_IA32_PEBS_ENABLE model-specific register on VM-Entry, the code consulted host masks without sufficiently respecting the vCPU’s (guest’s) requested PEBS_ENABLE bits. The result: the guest can be left running with PEBS enabled even when it didn’t request PEBS, which leads to a torrent of page faults if the guest’s PEBS-related state (for example MSR_IA32_DS_AREA) isn’t initialized.
• Why it matters. Unexpected PEBS enablement commonly manifests as near-infinite page-fault storms (#PF) that can crash or hang the guest VM. While the bug is localized to guest stability (not, in itself, a remote code execution path against the host), a crashing VM is a serious reliability problem and can be weaponized in multi-tenant/cloud contexts.
• Where it lives. The vulnerability is in the upstream Linux kernel perf/x86/intel area and is visible in vendor advisories and the kernel mailing list patch discussions. Multiple downstream distributions issued kernel fixes or advisories once the upstream commit was merged and stable branches were backported.

Understanding the technical pieces — PEBS, MSR_IA32_PEBS_ENABLE, and perf/KVM — is important for assessing exposure:

• PEBS (Precise Event-Based Sampling) is an Intel hardware mechanism for low-overhead sampling of microarchitectural events. It depends on a per-CPU buffer (the “DS area”) and therefore must be coordinated with a guest’s view of memory.
• MSR_IA32_PEBS_ENABLE is the model-specific register that controls whether PEBS is active; if PEBS is enabled but the guest has not configured the DS buffer, attempts to record PEBS events will fault.
• KVM + perf: KVM relies on the kernel perf subsystem to proxy virtual PMU events for guests. Because perf events are shared between host userspace and KVM’s guest-side logic, careful masking is required when building the MSR values to be installed for guests.

Upstream kernel discussions and vendor advisories indicate the fix consists of ensuring the guest’s desired PEBS bits are masked into the value loaded on VM-Entry so that the guest’s runtime cannot be tricked into enabling PEBS by host-side perf activity.

---

What Microsoft has said — and what that wording actually means​

Microsoft’s update page for CVE-2025-37936 states that Azure Linux “includes this open‑source library and is therefore potentially affected,” and that Microsoft will update the CVE entry if additional Microsoft products are found to be impacted. That wording should be read precisely:

• Confirmed inclusion: Microsoft has done a product-level mapping and can confirm that the Azure Linux family it maintains ships the upstream component that contains the vulnerable code — so Azure Linux is a confirmed item to patch or verify.
• Scoped attestation, not an exhaustive exclusion: The statement does not assert that Azure Linux is the only Microsoft product that could include the vulnerable code. It simply reflects Microsoft’s current inventory and the fact they have turned on CSAF/VEX-style attestations for that product family first.
• Why this matters operationally: Security teams often see vendor attestation and assume it means “only this product is affected.” With components that exist in widely reused upstream trees (the Linux kernel, in this case), that assumption is unsafe. Microsoft’s cautious language is designed to avoid overpromising while they finish inventorying and mapping additional artifacts.

In short: treat Azure Linux as a confirmed Microsoft product that includes the vulnerable code — and treat other Microsoft kernel deliveries as “under investigation” until you or Microsoft can confirm otherwise.

---

Are other Microsoft products likely to include the same code?​

Answer: Yes — technically possible and in many cases likely — but it depends on the product and the kernel artifacts it ships.
Concrete reasons why other Microsoft products might carry the same code:

• Microsoft maintains and distributes multiple Linux-kernel-based artifacts beyond the Azure Linux images. A prominent example is Windows Subsystem for Linux (WSL) / WSL2: Microsoft publishes a WSL2 kernel source tree and ships Windows-side kernel binaries built from that source to WSL clients. That kernel source includes components from the upstream tree (including perf and intel PMU code), and it is rebuilt and shipped on its own cadence.
• Microsoft also builds Azure-tuned kernel images for VMs and publishes kernel packages for certain Azure images; those Azure-specific kernel builds use upstream code as a base and therefore can carry upstream vulnerabilities until they are patched/backported.
• Marketplace images, AKS node images, and managed services that deploy Linux VM images may be using kernel packages or images that Microsoft builds, maintains, or curates; if those images contain the vulnerable commit range and the relevant kernel config includes the perf/KVM pieces, they are potentially affected.

What this means practically: any Microsoft product or artifact that includes a Linux kernel — particularly when that kernel’s config enables perf/KVM or the relevant CPU features — should be treated as potentially in scope until you verify the exact kernel version and patch level.
Caveat and caution: not every kernel build that contains the perf/x86/intel code is necessarily vulnerable. The vulnerability depends on both the commit range (i.e., whether the build predates the upstream fix or contains the offending commit) and the kernel configuration (whether the code path is compiled in and enabled). Always confirm with version/commit-level checks rather than assuming.

---

How to determine whether a Microsoft-delivered artifact you run is affected — a practical checklist​

Below is an operational checklist you can hand to engineering or incident teams. These steps are quick and give a definitive answer for specific hosts/images.

• Inventory first
• List all places where Microsoft-published Linux kernels or kernel images run in your environment:
• Azure VM images (platform images and Marketplace images)
• Azure Linux family images (the Microsoft-maintained Azure Linux distro)
• AKS node pools (which kernel image do nodes run?)
• Any on-prem or developer systems using WSL2 (desktop/laptop fleet)
• Any other Microsoft-distributed Linux kernel images (CI runners, test images, etc.)
• Check kernel version and provenance
• On a running Linux system (VM or WSL), get the kernel version:
• Run uname -r and record the release string.
• If available, get the upstream version or build tag used for the Microsoft kernel. WSL publishes kernel sources and tags; Azure images usually expose package metadata.
• Compare to fixed releases
• Verify whether the kernel version you run is based on a release that received the upstream fix for CVE-2025-37936 or whether vendor packages included a backport. If your kernel predates the fix, assume vulnerable until confirmed otherwise.
• Check config and presence of KVM/perf components
• On the host or image, inspect the kernel config: zcat /proc/config.gz or check /boot/config-$(uname -r) for relevant build options:
• Look for CONFIG_PERF_EVENTS=y and KVM-related options such as CONFIG_KVM and CONFIG_KVM_INTEL.
• If these are disabled, the specific code path may not be present; still verify with vendor guidance.
• For WSL2
• Run wsl --status on the Windows host to get the WSL kernel version metadata.
• Inside WSL, run uname -r and check kernel release tag against upstream fix lists.
• Update WSL using wsl --update where applicable and install applicable Windows Updates that carry new WSL kernel binaries.
• If in doubt, contact vendor / apply patches
• If you cannot conclusively prove the kernel contains the fix, treat the instance as vulnerable and apply vendor updates or rebuild with patched source.

---

Command snippets and concrete checks​

Use these exact commands to inventory and check systems quickly.

• Check kernel release on Linux/WSL:
• uname -r
• Check kernel config (if available):
• zcat /proc/config.gz | grep -E 'PERF|KVM|IA32_PEBS|PEBS'
• OR: grep -E 'CONFIG_PERF|CONFIG_KVM|CONFIG_KVM_INTEL' /boot/config-$(uname -r)
• Confirm whether perf events are permitted for unprivileged users (mitigation):
• sysctl kernel.perf_event_paranoid
• /proc/sys/kernel/perf_event_paranoid
• WSL-specific:
• From Windows host: wsl --status and wsl --update
• Inside WSL distribution: uname -r; inspect /proc/config.gz if present

If the kernel release and configuration indicate an outdated build that predates the upstream fix, update the kernel via your vendor channel (Azure Linux kernel package update, Microsoft WSL update, or apply the kernel rolling updates for your chosen distribution image).

---

Short-term mitigations you can apply now​

If you cannot immediately patch, consider these operational mitigations to reduce risk and blast radius:

• Restrict perf usage. Limit which users can create perf events. Raising kernel.perf_event_paranoid reduces unprivileged access:
• sysctl -w kernel.perf_event_paranoid=2 will strictly limit perf access (value semantics may vary by kernel series; confirm on your systems).
• Remove or restrict perf tooling in untrusted contexts. Disallow use of perf by non-admin users or in multi-tenant contexts where untrusted users can create events that might influence KVM guest state.
• Harden VM image build and CI pipelines. Ensure that images used to instantiate VMs on Azure or elsewhere are rebuilt from patched kernel sources or updated packages.
• Apply principle of least privilege for VM access. Limit who can run arbitrary tools on hypervisor hosts or host-level perf tooling on cloud images.

These mitigations are not a substitute for applying the vendor kernel fix, but they reduce exposure from user-space actions that can trigger the bug.

---

Patching and vendor mapping — what to expect​

• Upstream kernel developers merged fixes and backports; distribution vendors (Ubuntu, Debian, SUSE, Red Hat, Oracle, etc.) issued advisories and fixed kernel package releases or backports for their supported branches.
• Microsoft’s public attestation for CVE-2025-37936 has, to date, been applied to Azure Linux images. Microsoft indicated they will update the CVE if other Microsoft products are identified as affected. This is a normal lifecycle for multi-artifact vendors: start with products you manage and have inventory for, then expand attestations as mappings complete.
• Where possible, prefer vendor-supplied, packaged kernel updates rather than DIY kernel rebuilds. Vendor packages include distribution-specific backports and configuration choices relevant to the environment.

---

Risks, limitations, and caveats​

• This CVE is primarily a guest stability and DoS-style impact. It causes guest crashes by enabling PEBS unexpectedly. At present the public discussion and advisories emphasize reliability impact (near-infinite #PF), not remote host compromise. That said, in multi-tenant cloud contexts, anything that can crash a VM can be escalated into broader operational incidents.
• Inventory gaps are the real threat vector. The larger risk is not the technical novelty of the bug but the possibility that teams assume “only Azure Linux” is affected and therefore skip checks against WSL kernels, AKS node images, or other Microsoft-curated kernel artifacts.
• Vendor attestations lag reality. Microsoft’s MSRC attestation is authoritative for the product families it lists, but those attestations are only as comprehensive as the vendor’s current inventory mapping. Don’t treat the absence of a product on MSRC as proof of non-inclusion — instead treat it as “not-yet-stated.”
• Verifying kernel content matters. Two kernels with the same uname -r string from different vendors can have different patches or backports. Always validate against the vendor’s advisory or the source-level patch set.

---

Recommended action plan for IT and security teams​

• Treat Azure Linux as confirmed in-scope; patch immediately. If you run Azure Linux images, apply Microsoft’s kernel updates or the distribution patch that fixes CVE-2025-37936.
• Inventory all Microsoft-supplied kernels in your estate. Include WSL2 instances, Azure Marketplace images, AKS nodes, CI runners and developer workstations that may use Microsoft-supplied kernels.
• Run the checks listed above (uname -r, /proc/config.gz, sysctl values) to determine each artifact’s status.
• Apply vendor updates (Microsoft WSL updates, Azure image updates, distribution kernel packages) as soon as they are available for your artifact.
• Implement short-term mitigations where immediate patching is not possible (restrict perf use, increase perf_event_paranoid, reduce unprivileged access).
• Monitor vendor advisories and MSRC updates. Microsoft has committed to updating CVE entries when additional products are found to be affected; subscribe to your vendor feeds and integrate them into your patch management system.

---

Final analysis and takeaways​

• Microsoft’s public statement that Azure Linux “includes this open‑source library and is therefore potentially affected” is an accurate representation of the company’s product mapping work — but it is purposely scoped and conservative. It confirms Azure Linux as a Microsoft product that ships the vulnerable upstream code, not that it is the only Microsoft product that possibly does.
• From a technical perspective, any Microsoft product that ships a Linux kernel or kernel modules built from upstream commits that predate the fix — and that enables perf/KVM code paths — could carry the vulnerability. WSL2 and Azure‑tuned kernels are the most obvious artifacts to check beyond Azure Linux images.
• The attack surface here is primarily guest stability (Denial‑of‑Service via page faults) rather than host takeover, but the operational impact in cloud and multi-tenant contexts is significant enough to treat this as a priority patch.
• Practical, immediate steps are straightforward: inventory, check kernel versions/configs, apply vendor updates, and restrict perf usage until patched.
• Finally, treat vendor product attestations as starting points for an investigation rather than final closure. Where an upstream open-source component is widely reused, defensive security requires proactive verification across all artifacts and images you run — even those not yet named in a vendor’s CVE product mapping.

If you need a concise runbook (commands, checks, and escalation steps) tailored to your environment — for Azure VM fleets, WSL endpoints, or AKS clusters — prepare an inventory snapshot and I will convert these checks into an actionable playbook you can hand to engineering or patch teams.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center