CVE-2025-37879: Azure Linux Needs Updates, WSL 2 Is Patched

CVE-2025-37879 is also not a vulnerability in a general-purpose “open-source library” in the usual user-space sense. It is a defect in

, part of the Linux kernel’s 9P client implementation. The affected paths process replies to 9P read and write requests. A server that returns a success response paired with a deliberately invalid negative byte count could cause the client to treat that value incorrectly, leading to a kernel null-pointer dereference rather than rejecting the reply.

The direct answer, then, is: Azure Linux is the only Microsoft product currently catalogued by Microsoft as affected, but it is not the only Microsoft product that includes 9P client code. WSL 2 is the important counterexample—and the available public source indicates it is already fixed rather than presently vulnerable.

Microsoft’s CVE entry is an affected-product statement​

Microsoft’s August 11, 2026 Security Update Guide entry says Azure Linux is the only Microsoft product known to include the vulnerable open-source component and therefore potentially affected. It also says Microsoft will update the record if impact to additional products is identified.

That language is appropriately narrow. It establishes Microsoft’s supported-product assessment for this CVE; it does not provide a complete inventory of every Microsoft-delivered artifact that has ever carried related Linux kernel source. In particular, it does not name WSL, Windows Server, Azure host infrastructure, AKS node images, or third-party Linux distributions running on Azure. Nor does it provide an explicit statement that 9P is absent from those products.

Microsoft’s own Azure Linux vulnerability record, mirrored by the OSV database as AZL-70153, identifies the

RPM on Azure Linux 2 as affected through version

. Separately, Tenable’s Azure Linux local-security check shows that Azure Linux 3 systems below Microsoft’s tested package level were also subject to an update for CVE-2025-37879. Tenable dates the corresponding Azure Linux 3 patch publication to July 8, 2025.

The unusual part is timing. The upstream Linux CVE was published on May 9, 2025; Azure Linux patch metadata points to remediation in 2025; but the MSRC page supplied here is marked published on August 11, 2026. That means the MSRC entry should not be treated as the first availability of a fix. It is better understood as a later Microsoft product-scope disclosure, apparently aligned with the company’s newer CSAF/VEX publication process.

WSL 2 contains 9P support, but the public branch is patched​

Microsoft’s WSL2-Linux-Kernel repository describes itself as the source and configuration set for the Linux kernel used by Windows Subsystem for Linux 2. Its public

configuration enables all of the kernel features that matter here:

• CONFIG_NET_9P=y enables the 9P network client.
• CONFIG_NET_9P_VIRTIO=y enables the virtio transport commonly associated with virtualized 9P use.
• CONFIG_9P_FS=y enables the 9P filesystem client.

That is enough to disprove a broad reading of “Azure Linux is the only Microsoft product that includes this component.” WSL 2 includes it too, and it does so deliberately: 9P is part of the machinery historically used to make Windows-host files accessible inside a WSL Linux environment.

But the current WSL source is not vulnerable to this particular bug. Microsoft’s public x64 WSL configuration identifies the kernel as

. The Linux kernel CVE team says the 6.6 stable line received the correction in version 6.6.89. More importantly than the version comparison, the current WSL

source declares the read and write reply counters as unsigned

values and rejects a returned count larger than the requested size—the change described by the upstream fix.

That distinction is the practical answer to the apparent contradiction. WSL 2 includes the relevant 9P subsystem, but the current public WSL kernel source already has the remediation. There is no evidence in the Microsoft advisory, the upstream CVE record, or the public WSL source that Microsoft considers current WSL 2 installations affected by CVE-2025-37879.

There is one limitation: a public repository branch is strong evidence about Microsoft’s current source and configuration, but it is not a complete forensic inventory of every WSL kernel build ever shipped. Organizations using a pinned, older WSL kernel—or a custom kernel configured with 9P—should check the kernel they actually boot, rather than infer safety from the Windows version or WSL application version alone.

The bug needs a malicious 9P peer, not a listening Windows service​

The upstream Linux kernel announcement explains the failure precisely. In the vulnerable code, the kernel handles a successful 9P read or write reply, retrieves the count returned by the server, and checks whether it is no larger than the request. Because both values were signed, a negative reply count could pass the comparison. The subsequent processing could then result in a null-pointer dereference.

The patch changes those values to unsigned types. A malformed value such as negative one is then interpreted as

, clearly larger than a normal request size, and is rejected as a bogus 9P reply.

This is important for triage because CVE-2025-37879 is not a conventional “open port on the internet” flaw. A vulnerable Linux kernel must act as a 9P client and receive a crafted reply from a 9P server or endpoint it is communicating with. That can arise in specialized virtualized, distributed-filesystem, development, or container workflows, but it is not equivalent to exposing a network daemon merely because the 9P client code exists in the kernel.

The National Vulnerability Database and the Linux kernel CNA do not agree on severity. NVD assigns CVSS 7.1 with a local attack vector and low privileges required. The Linux kernel CNA’s record carries a 9.8 critical vector with network access and no required privileges. The technical description supports the conclusion that an attacker needs control over—or the ability to influence—a 9P server response consumed by the victim kernel. That is a materially narrower condition than an unauthenticated attacker reaching a generic network service, and admins should not let the higher CNA score erase that prerequisite.

Neither NVD nor Microsoft’s advisory identifies known exploitation in the wild. Tenable likewise lists no known exploits for the Azure Linux detection it published. That does not remove the need to patch an affected kernel, but it does place this CVE below actively exploited remote-code-execution bugs in an emergency patch queue.

Azure Linux administrators should verify the running kernel, then reboot​

For Azure Linux, the important operational point is that a package update alone does not remove the vulnerable kernel from memory. The system has to boot into the updated kernel.

Microsoft’s vulnerability data identifies Azure Linux 2 kernel builds through

as affected. Azure Linux 3 also received a security update, but the public MSRC entry does not state a fixed Azure Linux 3 kernel package version, affected image tags, rollout dates for managed Azure services, or whether a service image is customer-patchable. Those omissions matter for customers running Azure Linux outside an ordinary self-managed virtual machine.

On a self-managed Azure Linux host, administrators should establish three facts:

1. Confirm the installed and running kernel versions, because the RPM database and uname -r can differ until reboot.
2. Apply the current Azure Linux kernel update from Microsoft’s configured repositories.
3. Reboot and confirm that the active kernel is the updated build.

A host that has 9P compiled in but never establishes a 9P mount or transport session has a smaller exposure surface for this specific defect. It is still prudent to apply the vendor’s kernel update, because configuration can change, workloads can introduce 9P use, and package vulnerability management should follow the vendor’s affected-range determination rather than an assumed absence of use.

The right conclusion is narrower than Microsoft’s wording suggests​

Microsoft is correct, on the public evidence, to list Azure Linux as the Microsoft product requiring customer action for CVE-2025-37879. Azure Linux 2 and Azure Linux 3 kernel update records show that Microsoft tracked and remediated affected packages, and Azure Linux users should ensure their systems are booted into current kernels.

But Azure Linux is not the only Microsoft product whose Linux kernel source includes the affected 9P subsystem. WSL 2’s publicly maintained kernel configuration enables 9P networking, virtio 9P transport, and the 9P filesystem. The reason WSL 2 is absent from the affected-product list appears to be that its current public 6.6.107.1 branch includes the upstream correction that landed in Linux 6.6.89—not that WSL lacks the code.

For Windows and WSL administrators, the actionable outcome is straightforward: do not open an Azure Linux incident merely because a workstation has WSL installed, but do verify any custom, pinned, or long-unupdated WSL kernel that might predate the May 2025 fix. For Azure Linux administrators, update the kernel and reboot; Microsoft’s own affected-package data confirms that older builds were in scope.