CVE-2025-37980: Azure Linux Only Microsoft Product Affected

CVE-2025-37980 is a defect in the Linux block layer, specifically the

error path in

. When a multi-queue block-device registration proceeds far enough to create sysfs resources and then fails later, the older code did not call

before releasing the queue object. The result is a resource leak, rather than an immediate arbitrary-code-execution bug.

Microsoft’s wording also calls the Linux kernel an “open-source library,” which is imprecise. This CVE concerns the Linux kernel itself, including its block I/O and sysfs code, not a user-mode library that an application simply links against. That distinction affects triage: a Windows application using an open-source component is not implicated by this CVE merely because it uses open-source software; the affected code must be present and running in a Linux kernel build that contains the vulnerable block-layer path.

Microsoft’s answer is narrow, but meaningful​

The Microsoft Security Response Center record says Azure Linux is the only Microsoft product that includes the component and is therefore potentially affected. MSRC also says its CSAF and VEX publishing program, started in October 2025, is intended to make those product-impact decisions transparent.

In practical terms, this is Microsoft saying that its internal inventory has found the relevant vulnerable code in Azure Linux, but has not identified an affected version of Windows, Windows Server, Azure Stack HCI, Microsoft 365, or another named Microsoft product. It is not a blanket declaration that no other Microsoft offering has ever shipped Linux code.

That difference is visible in Microsoft’s own public projects. Microsoft maintains the Linux kernel used by WSL 2 in the public

project, and the WSL project explicitly identifies it as the kernel shipped with WSL. WSL therefore plainly involves Linux kernel code. But a product can contain the Linux kernel and still be unaffected by a particular kernel CVE if its shipped branch already includes the relevant upstream fix or does not expose the vulnerable configuration.

The MSRC wording supports exactly that more limited conclusion: Azure Linux is the only Microsoft product currently listed as potentially affected by CVE-2025-37980. It does not establish that WSL 2 or every other Microsoft-managed Linux environment is free of Linux kernel code, nor does it substitute for checking the actual kernel version in a deployed environment.

The upstream fix predates Microsoft’s advisory​

The Linux kernel stable-maintenance record shows that the fix was accepted upstream in April 2025. Zheng Qixing’s patch adds the missing

cleanup call after the debugfs cleanup label in

. The stable-tree notice identifies upstream commit

and says the defect dates back to the introduction of the multi-queue block I/O mechanism.

The CVE itself was published on May 20, 2025. NVD’s current enrichment identifies Linux kernel versions from 3.13 onward as affected until the fix reaches each maintained stable branch. The recorded fixed versions are:

• Linux 6.1.168 for the 6.1 stable branch.
• Linux 6.6.88 for the 6.6 stable branch.
• Linux 6.12.25 for the 6.12 stable branch.
• Linux 6.14.4 for the 6.14 stable branch.
• Linux 6.15 and later through the original upstream fix.

That timeline makes Microsoft’s August 11, 2026 posting look less like a newly discovered defect than a late product-specific disclosure or VEX-style inventory update. The technical fix had been public for roughly 16 months by the time the MSRC record appeared, and Linux distributors had already been incorporating it into their supported kernel streams.

This matters because a newly published CVE ID can create the impression that administrators face a fresh emergency. Here, the code fix is old enough that a fully patched Azure Linux estate may already be protected. The security work is not to chase the CVE publication date; it is to establish whether any deployed image or pinned kernel package remains below the fixed revision or lacks the backported patch.

Azure Linux 3 packages now sit beyond the fixed 6.6 threshold​

Microsoft’s public Azure Linux package repository currently lists

packages for Azure Linux 3.0. That is well beyond upstream Linux 6.6.88, the fixed 6.6-series version recorded by the Linux CVE data and NVD.

On that evidence, Azure Linux 3 systems fully updated to the currently published 6.6.145.2 package should contain the upstream stable fix. The same is true for the newer 6.18-series high-water-mark kernel packages listed in the repository, assuming they derive from their corresponding upstream stable releases without a deliberate reversion of this specific patch.

Tenable’s Azure Linux 3.0 plugin also shows that a Microsoft kernel security update addressing CVE-2025-37980 had been recognized before this MSRC posting. Tenable published the plugin on January 22, 2026 and describes Azure Linux 3 hosts as affected when their installed kernel is older than the plugin’s tested fixed version. The plugin does not provide enough public detail to establish Microsoft’s first patched Azure Linux package revision, so administrators should not treat its publication date as the exact remediation date.

Microsoft’s advisory leaves out several facts that would make this easier to audit. It does not publicly name the affected Azure Linux release, provide a minimum fixed RPM version, state whether Azure Linux 2.0 was in scope, or say whether the finding covers base images, container images, Marketplace virtual machine images, or all of the above. It also does not attach a KB-style update reference, because Azure Linux remediation is delivered as RPM packages rather than Windows cumulative updates.

For administrators, the absence of an explicit fixed package is the most consequential omission. Version comparison against generic upstream Linux releases is useful, but it is not a replacement for a vendor statement in distributions that backport patches without changing the visible upstream base version.

This is an availability issue in a constrained block-device failure path​

NVD assigns CVE-2025-37980 a CVSS 3.1 score of 5.5, Medium, using the vector

. In plain terms, NVD assesses it as locally reachable, requiring low privileges, with no confidentiality or integrity effect, but with potentially high availability impact.

That assessment needs context. The flaw does not describe a normal block-device operation leaking memory on every disk access. It occurs when registration of a block queue first succeeds far enough to create multi-queue sysfs resources and then later enters an error path. Repeatedly reaching that failure condition could consume kernel resources, but the CVE description does not establish a simple universal trigger, a remote attack path, or public exploitation.

The appropriate priority is therefore different from that of a remotely reachable kernel memory-corruption flaw. For Azure Linux operators, this belongs in routine kernel-update and image-hygiene work, with faster action for hosts that allow untrusted local users, dynamic storage provisioning, container workloads with unusual device access, or repeated block-device initialization failures. It does not justify treating every Azure Linux machine as exposed to an Internet-facing compromise.

Windows users should also avoid conflating this advisory with a Windows kernel vulnerability. CVE-2025-37980 does not apply to the Windows NT kernel. A Windows PC becomes relevant only where it runs a Linux kernel environment, such as WSL 2, a Linux virtual machine, or a container host. For WSL 2 specifically, the relevant check is the WSL kernel version reported by

or

inside a WSL 2 distribution—not the Windows build number.

What to verify before closing the ticket​

Azure Linux administrators should inventory the running kernel, not merely the installed RPM database. A system can have a fixed package installed yet remain booted into an older vulnerable kernel until it is restarted.

The most useful checks are straightforward:

• Confirm the kernel actually running on each Azure Linux host with uname -r.
• Compare the installed and running Azure Linux kernel packages against the organization’s approved current repository version.
• Reboot hosts that received a kernel package update but have not started the new kernel.
• Review golden images, immutable node templates, and long-lived containers that may still carry old kernel assumptions even when the host repository is current.
• Treat WSL 2 separately from Azure Linux and update WSL through Microsoft’s supported servicing path if its Linux kernel is stale.

The evidence supports a narrow conclusion: Microsoft currently identifies Azure Linux, not Windows, as the Microsoft product potentially affected by CVE-2025-37980. But the more useful operational conclusion is that current Azure Linux 3 kernel packages have already moved beyond the upstream 6.6.88 fix point. The remaining exposure is likely to be found on systems pinned to old images or kernels that were installed but never rebooted.