Microsoft has confirmed that its Azure Linux distribution is potentially affected by a recently disclosed Linux kernel vulnerability in the RDMA subsystem, urging customers to apply updates. But the same underlying code—and the need for a fix—could extend further into the company’s ecosystem, including Windows Subsystem for Linux (WSL2) and certain Azure virtual machine images, making inventory checks essential for security teams.

CVE-2025-37867, tracked in public databases, stems from an upstream Linux kernel issue where fuzzing tool syzkaller triggered an oversized memory allocation warning in the RDMA/core code path. The upstream fix adds a __GFP_NOWARN flag to suppress the noisy warning, improving kernel stability rather than patching a remote exploit. Microsoft’s Security Response Center (MSRC) published an advisory stating that Azure Linux “includes this open-source library and is therefore potentially affected.” The advisory also marks a shift in Microsoft’s disclosure process, with machine-readable CSAF/VEX attestations now rolling out to provide precise, product-level vulnerability information.

The kernel change and Microsoft’s advisory

The vulnerability involves a kvmalloc() call in the RDMA/core subsystem that, under certain conditions, generated a kernel warning. The warning itself does not represent a privilege-escalation or remote-code-execution vector, but in systems heavily using RDMA—think high-performance computing clusters, storage targets, or InfiniBand networks—it could indicate allocation handling issues that affect availability. Upstream maintainers resolved it by adding the __GFP_NOWARN flag, a defensive adjustment rather than a deep security hardening.

On its update guide page for CVE-2025-37867, Microsoft wrote: “Azure Linux includes this open-source library and is therefore potentially affected.” This is an authoritative, product-scoped statement. It means Microsoft’s internal inventory confirmed that the Azure Linux kernel family contains the vulnerable code. Microsoft also committed to updating the CVE mapping if additional products are found to ship the same component, and it highlighted a new CSAF/VEX attestation program that began in October 2025 to make such mappings machine-readable.

Which Microsoft products might be affected?

Microsoft’s advisory names only Azure Linux, but that does not mean other Microsoft-distributed kernels are safe. The presence of the upstream RDMA/core code depends on three factors: the kernel version and patch set used, the build configuration (whether RDMA drivers are enabled), and any vendor-specific backports.

Microsoft maintains several Linux kernel artifacts beyond Azure Linux:
- WSL2 kernels: The kernel that powers Windows Subsystem for Linux is built from a publicly maintained Microsoft repository. Public module listings show that WSL2 kernels include RDMA/InfiniBand modules like mlx5, ib_core, and ib_uverbs in certain builds. If those builds predate the upstream fix, they could be vulnerable.
- linux-azure and Azure Marketplace images: Virtual machine images in the Azure Marketplace often ship with Microsoft-tuned kernels. These kernels may share the same upstream RDMA code, depending on their version and configuration.
- Specialized or partner kernels: Microsoft consumes or distributes other kernels for specific offerings, which could also carry the code.

Because Microsoft has not yet attested to any of these additional products, security teams must verify them independently. The advisory should be treated as a starting point for Azure Linux remediation, not as an exhaustive list of affected Microsoft artifacts.

What this means for you

If you run Azure Linux

Treat the MSRC advisory as a confirmed finding. Apply the vendor update that includes the __GFP_NOWARN fix immediately. Microsoft’s new VEX/CSAF attestations will help automate detection for Azure Linux images once consumed by your vulnerability management tools.

If you run other Microsoft kernels (WSL2, linux-azure, marketplace images)

Do not assume safety. Inventory all Linux kernel artifacts in your environment and check for the presence of RDMA modules. Use lsmod or inspect /lib/modules/<version>/kernel/drivers/infiniband/. If RDMA drivers are present and the kernel predates the upstream fix (generally versions before May 2025), consider the system potentially affected.

If you run third-party Linux images in Azure

Vendor kernels from other distributions may also contain the RDMA code. Verify with your distribution’s security advisories and apply patches accordingly.

How we got here: RDMA, fuzzing, and transparency

The upstream kernel fix emerged from syzkaller, a kernel fuzzer that stresses interfaces with random inputs. Fuzzing often surfaces edge-case warnings that developers later silence to reduce noise and improve reliability. This CVE is a typical example: a warning that could appear under stress or unusual allocation paths, with no public exploit demonstrating remote code execution.

For Microsoft, the advisory represents more than just a routine kernel update. The company has been scaling its Linux operations, from Azure Linux—a cloud-optimized distribution originally derived from CBL-Mariner—to WSL2 kernels that bring a full Linux environment to Windows. This broad footprint means that a single upstream patch can ripple across multiple Microsoft products. The CSAF/VEX attestation program, introduced in October 2025, aims to bring clarity to this complexity by providing machine-readable statements about which products are affected, under investigation, or fixed.

What to do now

  1. Patch Azure Linux immediately. Follow Microsoft’s update guidance and consume the VEX entries to confirm remediation status.
  2. Inventory all Linux kernels in your environment. Record kernel versions (uname -r) and check for InfiniBand/RDMA modules. A quick command: ls /lib/modules/$(uname -r)/kernel/drivers/infiniband/ will show if the RDMA subsystem is present.
  3. Prioritize systems with active RDMA workloads. Hosts running HPC, NVMe-oF, or InfiniBand are most exposed because they actively exercise the vulnerable code paths.
  4. Automate VEX consumption. Integrate Microsoft’s CSAF/VEX feed into your vulnerability management pipeline so that future product mappings are automatically reflected.
  5. Verify upstream commit presence. If you can inspect the kernel source or build metadata, look for the commit that adds __GFP_NOWARN. If unsure, patch or quarantine until verified.

Outlook: greater transparency, but verification still required

Microsoft’s VEX/CSAF rollout is a significant improvement, moving from opaque advisories to machine-readable, product-specific vulnerability information. However, the current attestation covers only Azure Linux. Until Microsoft completes inventories for WSL2 kernels, marketplace images, and other artifacts, operators must continue to verify their Linux kernels manually. The company has promised to expand coverage over time, which will ultimately reduce this manual burden. For now, treat Azure Linux as a confirmed carrier, patch it, and verify everything else.

Microsoft’s advisory page for this CVE is available at the MSRC update guide.