Microsoft has publicly acknowledged that its internally maintained Linux distribution, Azure Linux, is affected by CVE-2025-38351, a kernel vulnerability that can allow a guest virtual machine to destabilize the underlying hypervisor on Intel-based hosts. The company also announced that it is expanding machine-readable vulnerability attestations through CSAF/VEX, promising faster automated triage for defenders—while cautioning that other Microsoft-distributed Linux kernels, including those used in WSL2, AKS, and Marketplace images, have not yet been ruled out.

The vulnerability at a glance

The flaw lies in how the Linux kernel handles paravirtualized TLB (Translation Lookaside Buffer) flush hypercalls when running as a guest on Hyper‑V hosts. In affected code paths, the kernel accepts a list of guest virtual addresses (GVAs) from the guest and attempts to invalidate them via CPU instructions such as INVVPID (Intel) or INVLPGA (AMD). The problem? The kernel never validated whether those addresses were canonical—that is, properly formed according to x86‑64 address space rules.

On Intel processors, INVVPID explicitly faults on non‑canonical addresses; on AMD, INVLPGA treats them as a no‑op. That discrepancy doesn’t just mean different behavior—it can lead to failed invalidations, kernel warnings, and, in more serious scenarios, host instability or denial of service. A malicious or compromised guest that has permission to issue these hypercalls could actively exploit the gap, especially in multi‑tenant cloud environments.

Microsoft’s security advisory lists Azure Linux as a product that includes the vulnerable upstream library, making it “potentially affected.” The fix is already available through standard Azure Linux kernel updates.

Who is affected—and who isn’t

For now, Azure Linux users have a clear signal: patch. But the more nuanced answer matters for anyone who runs Linux workloads on Microsoft infrastructure. The advisory’s wording—carefully scoped to Azure Linux—doesn’t mean every other Microsoft‑supplied kernel is in the clear.

Azure Linux customers

  • Who you are: You run Azure Linux (formerly CBL‑Mariner) as a host operating system, in Azure VM images, or as a base layer for containers.
  • What to do: Apply the latest kernel updates through your normal update mechanism. For images you manage (e.g., in a pipeline), rebuild and redeploy. If you’re using Microsoft’s livepatch service, a hotfix may already be available; check your feed.

WSL2 users on Windows

  • Who you are: You use the Windows Subsystem for Linux 2 on Windows 10, 11, or Server. Your WSL2 instance runs a Microsoft‑maintained kernel.
  • Why the uncertainty: Microsoft has not yet issued a VEX attestation for the WSL2 kernel, but the advisory explicitly leaves the door open: “If impact to additional products is identified, we will update the CVE.” The WSL2 kernel builds from the same upstream tree that contains the vulnerable code path. Whether the exploit path is actually reachable depends on the kernel configuration and the guest’s ability to issue the specific hypercalls.
  • What to do: Run wsl --status to check your kernel version, then wsl --update to install the latest Microsoft‑provided WSL kernel. If your organization distributes custom WSL kernels, treat them as self‑maintained artifacts and verify them yourself.

Cloud operators managing Azure VMs and AKS

  • Who you are: You deploy or manage Azure virtual machines, Azure Kubernetes Service nodes, or custom images from the Azure Marketplace.
  • The risk surface: Many Azure VM types use a linux‑azure kernel derived from Ubuntu or other distros; some may incorporate the same upstream Hyper‑V paravirtualization patches. AKS node images are regularly rebuilt and may also contain the vulnerable kernel code. Marketplace appliances sourced from Microsoft or third parties add another layer of uncertainty.
  • What to do: Inventory every image and running host. For each, check: Does it use a Microsoft‑distributed kernel? Is CONFIG_HYPERV enabled? What is the kernel version? Compare that version against the upstream fix commit (the commit that added canonical‑address validation). If you can’t confirm fix inclusion, treat the artifact as potentially vulnerable and patch or rebuild.

Home users and developers

  • Risk level: Lower, because the attack vector requires a malicious guest to intentionally craft hypercalls—a scenario more likely in shared cloud environments than on a single‑user workstation.
  • Action: If you run WSL2 for development, updating the kernel is quick and safe. No other user‑facing action is required.

How Microsoft is changing vulnerability reporting

Alongside the advisory, Microsoft pointed to a larger initiative: the phased rollout of CSAF (Common Security Advisory Framework) VEX (Vulnerability Exploitability eXchange) documents, which began in October 2025. These machine‑readable files explicitly link a CVE to a specific product and state whether that product is “Known Affected,” “Not Affected,” “Under Investigation,” or “Fixed.”

The immediate benefit for Azure Linux is that defenders can automate triage instead of manually parsing prose advisories. A vulnerability management platform that ingests the VEX feed will immediately flag affected Azure Linux hosts and suppress noise for products that are explicitly marked not affected.

But the rollout is phased. Starting with Azure Linux was operationally sensible—it’s a single distribution Microsoft controls end‑to‑end—but it also means that the absence of a VEX document for another Microsoft product (like WSL2 or a specific Azure VM kernel) means “not yet attested,” not “not affected.” Microsoft has committed to updating the CVE record and CSAF/VEX documents if additional products are found to include the vulnerable code.

Why a single CVE can ripple across many artifacts

This CVE highlights a structural challenge for vendors like Microsoft that distribute many distinct Linux kernel artifacts. When upstream fixes a bug in the KVM paravirtualization layer, that fix lands in the mainline kernel and is eventually backported to stable trees. But each artifact—Azure Linux kernel, WSL2 kernel, linux‑azure kernel for certain VM types, AKS node images—is built from its own branch, with its own set of backports and configuration tweaks.

A vulnerability may exist in one artifact but not another, even if both share a kernel version number. For example, a WSL2 kernel might have CONFIG_HYPERV and CONFIG_KVM both enabled, making the hypercall path reachable from a guest, while a minimal container‑host kernel might disable those options entirely. Even within Azure Linux, different kernel flavours (core, azure, etc.) may differ in exposure.

That’s why Microsoft’s measured, per‑product attestation approach is necessary—and why defenders cannot simply assume that a single CVE affects everything equally.

Your immediate action plan

Here are practical steps, ordered by priority. They apply whether you’re a cloud engineer, a security analyst, or an IT generalist.

1. Patch Azure Linux now

  • Apply the latest kernel updates on every Azure Linux host and rebuild any custom images that use Azure Linux as a base.
  • For Azure-based workloads, check for livepatch availability in supported regions.

2. Inventory all Microsoft‑distributed Linux artifacts

  • List every host, VM, container node, and developer machine that runs a Microsoft‑provided kernel. Include:
  • Azure Linux instances
  • WSL2 instances (via wsl -l -v on Windows)
  • VMs using the linux‑azure kernel (Ubuntu‑based images in Azure often default to this)
  • AKS node images (check node image version in Azure portal or CLI)
  • Marketplace or partner appliances (record image publisher and version)

3. Verify exposure at the artifact level

For each artifact, run (or script) the following checks:

uname -r                     # kernel version
cat /proc/version            # build metadata, vendor tags
grep CONFIG_HYPERV /boot/config-$(uname -r)  # Hyper‑V paravirt support

If CONFIG_HYPERV is present, the kernel has the infrastructure that could include the flawed code path. Next, map the kernel version to upstream stable branches: if your kernel is older than the version containing the fix (which landed in the 6.1.x, 6.6.x, and later stable series, depending on backport cadence), assume it is vulnerable until proven otherwise.

For WSL2, run:

wsl --status
wsl --update

The update command installs the latest Microsoft‑distributed WSL kernel. After updating, re‑check the kernel version inside WSL2 to confirm.

4. Ingest VEX/CSAF feeds when available

  • Connect your vulnerability management tooling to Microsoft’s CSAF feed for Azure Linux. This feed will automatically update when new attestations are published.
  • For products not yet attested, request an SBOM (Software Bill of Materials) from the image publisher if you’re using a Marketplace appliance. Cross‑reference the listed kernel package version against known‑good versions.

5. Monitor for exploitation attempts

  • Set up log alerts for kernel oopses, INVVPID errors, or unusual hypercall activity in host logs (dmesg, /var/log/messages).
  • In multi‑tenant environments, consider temporarily isolating or throttling guests that show anomalous hypercall patterns.

6. Keep an eye on MSRC

Microsoft’s advisory will be updated if other products are confirmed affected. Check back—or better, subscribe to the CVE change feed—so you can expand your remediation scope automatically.

The bigger picture

Microsoft’s adoption of VEX/CSAF is a welcome move for defenders weary of parsing ambiguous security bulletins. By naming a specific product (Azure Linux) and committing to a machine‑readable format, the company has given its cloud users a clear action path. But the phased nature of the rollout means that for now, security teams must do some of the legwork.

That’s a fair trade‑off. Azure Linux is the most obvious and widely deployed Microsoft‑controlled Linux artifact, so starting there focuses attention where it’s most needed. As the VEX program expands, the same automated triage that protects Azure Linux should eventually cover WSL2 kernels, AKS node images, and other artifacts—reducing the need for manual verification.

What to watch next

Two things will determine how this story evolves: first, whether Microsoft issues additional VEX attestations for other products. If WSL2 or a popular Azure Marketplace image gets flagged, the remediation scope will grow significantly. Second, how quickly the broader Linux community backports the fix to all stable kernels—especially those that underpin Ubuntu, Debian, and other distros that supply Azure VM images. The upstream fix is surgical, but deployment is always uneven.

For now, patch Azure Linux, verify your other Linux kernels, and set a reminder to re‑check Microsoft’s advisory in the coming weeks. A single sentence in a security bulletin is enough to start your investigation—but not enough to finish it.