Microsoft has published a machine-readable CSAF/VEX advisory confirming that its Azure Linux distribution is vulnerable to a recently disclosed Linux kernel bug tracked as CVE-2025-38375. The advisory marks the first time the company has used its new transparency framework to attest to a kernel-level flaw in a Microsoft-maintained Linux product, but it leaves administrators of other Microsoft-shipped Linux kernels—including the widely deployed Windows Subsystem for Linux 2 (WSL2)—without official guidance on their exposure.

What CVE-2025-38375 is and who’s affected

The vulnerability resides in the virtio-net driver, specifically in the receive path where a missing validation allows a received packet length to exceed the allocated buffer size. That oversight can trigger an out-of-bounds read, leading to kernel crashes or system instability. The Linux kernel community has published upstream fixes with precise commit IDs, and major distributors like Red Hat, SUSE, Debian, and Amazon Linux have released backported patches referencing this CVE.

Microsoft’s advisory names only one affected Microsoft product: Azure Linux. “One of the main benefits to our customers who choose to use the Azure Linux distro is the commitment to keep it up to date with the most recent and most secure versions of the open source libraries,” the advisory states. It then links to a blog post from October 2025 announcing the company’s rollout of CSAF/VEX (Common Security Advisory Framework / Vulnerability Exploitability eXchange) documents—a machine-readable format designed to eliminate guesswork when determining whether a given vulnerability applies to a specific product.

The language is careful. The advisory says Azure Linux is “potentially affected” because it ships the vulnerable open-source component. It does not claim that no other Microsoft product contains that same component. Instead, it promises: “If impact to additional products is identified, we will update the CVE to reflect this.” That promise is at the heart of the practical challenge for system administrators.

Why this advisory is different: Microsoft’s new CSAF/VEX transparency

For years, security advisories from large vendors often left customers to match vague component lists against their own inventories. A CVE might mention “libvirt” or “Linux kernel,” but without knowing whether vendor X actually shipped that library in product Y, IT teams could waste time chasing false positives—or worse, ignore a real threat.

Microsoft’s CSAF/VEX program, first announced in October 2025, changes that for its own portfolio. By issuing a machine-readable attestation that ties a CVE to a specific product, Microsoft gives Azure Linux customers a definitive, automatable answer. The CVE-2025-38375 advisory is one of the first public tests of this approach for a kernel-level issue, and it works as intended: Azure Linux operators can immediately flag the CVE as relevant and prioritize patching.

But the move also exposes a transparency gap. The VEX rollout is phased, and Azure Linux was the starting point—likely because it is Microsoft’s most visible and widely used in-house Linux distribution. The advisory’s existence proves the company can produce such attestations; its narrow scope reveals that the inventory work has not yet been completed for other Linux artifacts that Microsoft ships.

The missing pieces: WSL2 and other Linux artifacts

Beyond Azure Linux, Microsoft maintains several other Linux kernels or images that could, depending on their version and build configuration, include the same vulnerable virtio-net code:

  • WSL2 kernel: Microsoft ships a prebuilt Linux kernel with Windows to power WSL2 distributions. That kernel tree is maintained by Microsoft and may compile in virtio-net drivers. The latest WSL kernel version is available in release notes, but those notes do not currently reference CVE-2025-38375, and no CSAF/VEX attestation has been published.
  • CBL-Mariner and Azure host images: The underlying host OS for many Azure services is based on a Microsoft-maintained Linux distribution (formerly CBL-Mariner). Those images can include the virtio-net driver for networking. Again, no attestation.
  • Marketplace VM images: Azure Marketplace offers Linux images maintained by third parties, but some may be based on Microsoft’s own kernel builds. Each image needs independent inventory.

Without an official VEX document for these artifacts, administrators cannot assume safety. The absence of an attestation only means Microsoft has not finished—or perhaps not yet started—its formal inventory for that product. The advisory’s phrasing is a procedural reminder, not a technical guarantee.

This gap matters in real-world operations. WSL2 is used by developers, IT professionals, and in CI/CD pipelines. If the WSL2 kernel contains the unpatched code, a local attacker or a compromised container could theoretically crash the Linux subsystem. In cloud environments, multi-tenant hosts running a vulnerable virtio driver could be destabilized by a malicious guest. While current assessments classify this bug primarily as an availability risk with no known reliable remote code execution vector, denial-of-service in production environments is serious enough to warrant fast action.

What to do now: A practical guide for system administrators

Until Microsoft expands its attestations, the burden of verification falls on the teams managing these systems. Here is a prioritized plan.

If you run Azure Linux
The path is straightforward. Microsoft’s advisory confirms you are affected. Retrieve the fixed kernel version from Azure Linux release notes or the CSAF/VEX document and apply the update through your standard patch management. No further manual verification is needed because the attestation is definitive.

If you use WSL2
Start by checking your kernel version:

uname -r

Compare it against Microsoft’s WSL kernel release notes. As of now, no public patch explicitly references CVE-2025-38375. If you rely on the default WSL kernel, you should monitor two sources: the WSL release notes and Microsoft’s CSAF/VEX feed for any new attestation. If you have built a custom WSL kernel, you must verify that it includes the upstream fix commits. The Linux kernel CVE announcement lists the exact commit IDs; merge those into your kernel tree or rebuild with a patched baseline.

If you manage other Microsoft-maintained Linux images on Azure
Inventory every running instance. For each, examine the kernel config to check whether virtio-net is enabled:

grep CONFIG_VIRTIO_NET /boot/config-$(uname -r)

If the driver is present (either built-in or as a module), map the running kernel version to the fixed stable kernel branches. The upstream announcement details which kernel branches received the fix. If your kernel predates those fixes and your distribution (or Microsoft) has not released an update, take mitigating steps:
- Restrict who can trigger virtio operations on your hosts—limit device hotplug and vhost management-plane access to trusted users.
- Schedule a maintenance window to deploy patched kernels as soon as they become available.

General recommendations
- Bookmark the Microsoft Advisory for CVE-2025-38375 and monitor it for updates.
- Integrate CSAF/VEX data into your vulnerability scanning tools if possible; many commercial and open-source scanners can consume these feeds.
- For hybrid fleets, follow distribution-specific advisories from Red Hat, SUSE, Debian, and others. Their backported kernels often carry the same fix references.

How we got here: The path to Microsoft’s partial attestation

The vulnerability itself was reported through the usual kernel channels and fixed in upstream stable trees. Distributors began rolling out patches within days. Microsoft’s involvement, however, is uniquely tied to its October 2025 decision to adopt CSAF/VEX. That decision came after years of industry pressure for more transparent supply-chain security data, especially as governments and enterprises demanded machine-readable formats to automate vulnerability response.

Azure Linux, as Microsoft’s flagship Linux distribution, was the logical starting point for the program. The advisory for CVE-2025-38375 thus serves double duty: it alerts Azure Linux customers and demonstrates the new attestation system in action. The advisory’s reference to the October 2025 blog post confirms that this is a deliberate, phased rollout. The fact that only Azure Linux appears in the advisory tells us less about the safety of other products and more about where Microsoft has focused its initial inventory efforts.

Outlook: What’s next for Microsoft’s vulnerability attestations

Microsoft has explicitly committed to expanding CSAF/VEX attestations to additional products. When—not if—the company completes inventories for WSL2, Azure host images, and other Linux artifacts, the CVE record for CVE-2025-38375 will be updated accordingly. Administrators should expect a stream of similar advisories in the coming months as the VEX pipeline matures.

For now, the situation underscores a broader shift: machine-readable security data is becoming the norm, but its rollout is uneven. Until coverage is complete, IT teams must combine vendor attestations with manual checks. The Azure Linux advisory is a useful piece of the puzzle, but it’s not the whole picture.