CVE-2025-40102: Azure Linux Attestation and the Broader Microsoft Kernel Risk

Microsoft’s short advisory that “Azure Linux includes this open‑source library and is therefore potentially affected” is accurate — but it is a product‑scoped attestation, not a categorical statement that no other Microsoft product can contain the same vulnerable component.

Background / Overview​

CVE‑2025‑40102 is a Linux‑kernel KVM bug affecting the arm64 KVM codepath: KVM: arm64: Prevent access to vCPU events before init. The upstream reports and database entries describe a condition where userspace can pend vCPU events for a vCPU that hasn’t been initialized, allowing KVM to interpret uninitialised data and, in some interleavings, push a vCPU into an illegal execution mode that triggers a kernel BUG. Microsoft’s public Security Response guidance for this CVE includes a short product mapping statement: it identifies Azure Linux (the Microsoft‑maintained Linux distribution lineage used for Azure host and container images) as including the implicated open‑source component and therefore being potentially affected, and it explains that Microsoft began publishing machine‑readable CSAF/VEX attestations in October 2025 and will update the CVE/VEX records if additional Microsoft products are found to ship the same component. That is what Microsoft actually published; the phrasing is deliberate and procedural. This article unpacks what that wording means in practical and technical terms, compares independent sources to verify the core technical facts, explains why other Microsoft artifacts could plausibly carry the same vulnerable code, and gives operational guidance for operators and defenders who must triage Microsoft‑supplied images and kernels across a heterogeneous estate.

---

What the CVE actually is (technical summary)​

The bug, in plain language​

• Component: Linux kernel — the KVM arm64 vCPU event handling and injection paths.
• Fault: KVM accepted vCPU events from userspace before the vCPU had been properly initialized, letting uninitialised memory control routing/injection decisions. In one documented case the mismatch led to the vCPU being treated as a 32‑bit EL1 target on AArch64 and triggered a kernel BUG in exception handling.

This is a host/guest‑adjacent kernel correctness bug rather than a classic remote code execution primitive. The primary impact is availability and host stability: kernel oopses, vCPU failures, and in the worst case host reboots causing denial‑of‑service for tenants. Public trackers and vendor advisories classify the issue along these lines.

Fix and mitigation model​

The upstream fix is straightforward conceptually: reject IOCTLs that attempt to pend vCPU events for an uninitialized vCPU or otherwise guard code paths so injection only occurs after vCPU init completes. Distributors and cloud vendors must backport or ship kernels that contain this upstream resolution and then reboot affected hosts to complete remediation. Upstream commit references and vendor changelogs are the authoritative confirmation that a given kernel build contains the fix.

---

What Microsoft said — careful reading of the MSRC language​

Microsoft’s advisory text and the company’s October 2025 blog about rolling out CSAF/VEX attestations are clear on two points:

• Microsoft has published a machine‑readable VEX/CSAF attestation that maps specific CVEs to specific Microsoft product artifacts, starting with Azure Linux. That attestation declares Azure Linux includes the implicated upstream component and therefore is potentially affected.
• Microsoft committed to update those CVE/VEX mappings if additional Microsoft products are later found to ship the same upstream component. In other words: the initial attestation is phased and product‑by‑product.

Read together, those points mean Microsoft has finished the inventory and mapping work for the Azure Linux product family and made a deterministic attestation for that family. It does not mean Microsoft has finished scanning every Microsoft image, kernel build, or partner appliance company‑wide. Absence of an attestation for a product is not proof the product is unaffected; it simply means the vendor’s inventory work for that product isn’t yet published.

---

Is Azure Linux the only Microsoft product that includes the library and is therefore potentially affected?​

Short answer (operational): No — not necessarily. Azure Linux is the only Microsoft product Microsoft has publicly attested so far to include the implicated upstream code for this CVE, and that attestation is authoritative for Azure Linux customers as of December 7, 2025. But the attestation is product‑scoped; it does not prove that no other Microsoft product ships the vulnerable code. Microsoft has explicitly said it will update the CVE/VEX records as additional inventory work completes.

Why that nuance matters (technical reasons)​

• Kernel features and drivers are a build‑time property. Two kernel binaries built from the same upstream sources can include different subsystems depending on the CONFIG_* flags and packaging choices.
• Microsoft produces multiple, independently built Linux artifacts that either ship a kernel binary or run a kernel in a hosted environment: Azure Linux images (CBL‑Mariner lineage / linux‑azure), the Microsoft WSL2 kernel distributed with Windows, linux‑azure kernels used by some Azure VMs, Marketplace images and partner appliances, and curated AKS/AKS node images. Any of these can be a carrier for the same upstream code depending on build provenance and configuration.

In practice, that means: if a Microsoft product ships a Linux kernel binary that contains the vulnerable KVM code (or compiles it in as a module), it is a potential carrier — until inventory or SBOM/VEX attestation proves otherwise.

---

Which other Microsoft products are plausible carriers?​

Below are the most plausible Microsoft artifacts that could include the affected kernel code and therefore warrant verification:

• Windows Subsystem for Linux (WSL2) — Microsoft builds and distributes a Microsoft‑maintained Linux kernel for WSL2; that kernel’s sources and configuration are public and the binary gets shipped via Microsoft Update or as a WSL package. A WSL2 kernel built from an upstream branch predating the fix or with the vulnerable config could in principle include the same code.
• linux‑azure (Azure‑tuned kernels and Azure VM images) — Microsoft and some Linux distributors publish Azure‑specific kernel builds (often packaged as linux‑azure or similar) that are tuned for Azure VMs. These can and do diverge in configuration from stock distro kernels; if the problematic KVM code is present in those builds, Azure VM images may be affected beyond the Azure Linux distribution the VEX attestation initially covered. Canonical, for example, explicitly tracks and ships linux-azure kernels for Azure images.
• Azure Marketplace and curated VM images — Marketplace images are published by Microsoft partners and may include Microsoft‑supplied kernels or vendor kernels; their inclusion in Microsoft’s VEX outputs depends on the publisher and the inventory work the vendor performs. Marketplace images are not automatically covered by a single Azure Linux attestation.
• AKS node images and container host images (Azure Linux host for AKS) — AKS uses Microsoft‑maintained host images and kernel builds in many configurations; if those hosts use an affected kernel build, cluster nodes and managed node pools are in scope and require patching. Microsoft documents the Azure Linux host used for AKS nodes and the distribution’s role in node images.
• Third‑party products and custom builds — Any Microsoft product or partner image that bundles or builds a Linux kernel from the same upstream commit range can carry the vulnerable code. Absence of a VEX entry does not automatically exempt these artifacts.

For each of the above, the only reliable way to confirm presence/absence of the vulnerable code is an artifact‑level check (kernel config, package changelog, SBOM/VEX, or /boot/config-$(uname -r) on a running system). Microsoft’s VEX/CSAF outputs are designed to provide that deterministic mapping — but they are only authoritative for the products Microsoft has completed and published.

---

Verifying the claim: cross‑checks and independent sources​

Key claims — the CVE technical summary, Microsoft’s Azure Linux attestation, and the existence of other Microsoft kernel artifacts — are corroborated by independent sources:

• CVE technical description: both NVD and CVE aggregator pages describe the KVM arm64 issue and the upstream fix narrative (uninitialized vCPU event handling leading to kernel BUG). Use these upstream descriptors to confirm the exact nature of the footprint you must check for.
• Microsoft’s VEX/CSAF rollout and Azure Linux attestation: Microsoft’s MSRC blog and security guidance describe the October 2025 CSAF/VEX launch and explicitly state Azure Linux is the starting product for VEX attestations; Microsoft committed to expanding product coverage and updating CVE mappings if additional products are discovered to ship the same components. That confirms this attestation is an inventory outcome, not a binary claim of exclusivity.
• Other Microsoft kernel artifacts are public: Microsoft publishes the WSL2 kernel source and documentation for shipping Linux kernels in WSL, and Azure documents linux‑azure kernels used for Azure VMs and AKS host images. These public facts justify the operational stance that other Microsoft artifacts are plausible carriers and must be checked.

Where independent sources disagree about a detail (for example, whether a specific Marketplace image uses a Microsoft kernel or a vendor kernel), err on the side of artifact inspection rather than trusting a vendor attestation alone.

---

Operational guidance — what to do now​

If you operate systems that touch Microsoft‑provided images, follow this prioritized, practical playbook.

1. Treat Azure Linux artifacts as confirmed in‑scope (highest priority)​

• Identify all Azure Linux VMs, AKS node pools, container hosts and managed images in your estate.
• Apply Microsoft’s recommended kernel updates or patched images for Azure Linux immediately and schedule reboots as required. Microsoft’s VEX attestation is authoritative for Azure Linux — consume it in automation if possible.

2. Inventory other Microsoft artifacts (WSL, linux‑azure, Marketplace images)​

• Query WSL installations: check the WSL kernel version and the WSL2 kernel binary your Windows hosts are using (you can fetch the running kernel release inside the WSL VM and inspect /boot/config if available). WSL ships a Microsoft‑maintained kernel; if your WSL kernel predates the fix you must apply an updated WSL kernel.
• For Azure VMs and AKS nodes not running Azure Linux, inspect /boot/config-$(uname -r) or the kernel package changelog to confirm whether the upstream fix commit is present.
• For Marketplace images, reach out to the image publisher or inspect the image’s kernel binary and config directly.

3. Use SBOM/VEX/CSAF where available​

• Automate checks against Microsoft’s CSAF/VEX feed for product attestations. The VEX files are machine‑readable and are designed to be consumed programmatically to accelerate triage. Microsoft began publishing VEX in October 2025; consume those outputs as they appear and re‑run inventory checks when Microsoft updates a CVE mapping.

4. Detection and monitoring​

• Hunt host logs for kernel oopses and KVM‑related stack traces that match the failure modes described in CVE reports (messages referencing exception_target_el, pend_serror_exception, __kvm_arm_vcpu_set_events, etc.. These traces indicate active or attempted triggering of the vulnerable path and should trigger immediate containment and remediation.

5. If you can’t patch immediately — mitigations​

• Avoid running untrusted guests on hosts that could be vulnerable.
• For high‑risk multi‑tenant hypervisors, prioritize moving untrusted workloads to patched hosts or take hosts offline for maintenance (the definitive fix requires deploying patched kernels and rebooting). Temporary configuration changes are risky and may have side effects; they are stopgap only.

---

Risks, strengths, and what to watch for​

Strengths of Microsoft’s approach​

• Machine‑readable attestations (CSAF/VEX) let defenders automate triage and reduce false positives. Microsoft’s decision to publish VEX for Azure Linux was a deliberate, transparent first step that yields immediate value to Azure Linux customers.

Limitations and residual risks​

• Phased rollout invites misinterpretation. The public attestation for Azure Linux is often read by customers as “only Azure Linux is affected” — that is incorrect and risky. Operational teams that assume exclusivity risk missing vulnerable artifacts in WSL, linux‑azure kernels, Marketplace images or AKS nodes.
• Artifact variance. Because kernel inclusion is a build‑time choice, different SKUs can diverge quickly; the only reliable verification is artifact inspection or vendor attestation per product.
• Supply‑chain complexity. Marketplace images, partner appliances, and custom images complicate the mapping; ensure inventories cover third‑party images you run in Azure.

Flagging unverifiable claims​

• Microsoft’s public attestation is authoritative for the product it names. However, if a claim appears that “no other Microsoft products could include the code,” treat that as unverified unless Microsoft explicitly publishes a negative attestation for every product of interest. Microsoft has explicitly reserved the right to update the VEX mapping as its inventory work continues.

---

Conclusion — practical takeaways​

• Microsoft’s statement that Azure Linux includes the open‑source library and is therefore potentially affected is accurate and actionable for Azure Linux customers; it is a product‑level VEX attestation published as part of Microsoft’s October 2025 CSAF/VEX rollout. Treat that attestation as authoritative for Azure Linux and remediate accordingly.
• Azure Linux is not necessarily the only Microsoft product that could include the vulnerable kernel code. Several Microsoft artifacts — notably the WSL2 kernel, linux‑azure kernels used in certain VM images, AKS node images, and Marketplace images — can and do ship Linux kernels; any of these should be verified at the artifact level until Microsoft publishes explicit attestations for them.
• Operationally, prioritize: (1) patch and reboot Azure Linux hosts now; (2) inventory and verify other Microsoft‑provided kernels and images in your environment; (3) consume Microsoft’s CSAF/VEX outputs in automation and re‑classify assets as Microsoft updates attestations.

Microsoft’s move to VEX/CSAF is a net positive for defenders — it gives a deterministic signal for the artifacts Microsoft has checked. The defensive discipline required now is simple in principle and sometimes complex in execution: don’t treat absence of an attestation as absence of a problem. Verify the artifacts you run, and let machine‑readable vendor attestations reduce the burden of triage where they exist.

---

---

Source: MSRC Security Update Guide - Microsoft Security Response Center