CVE-2025-37867: Azure Linux RDMA Kernel Fix and MSRC Attestation Explained

CVE-2025-37867 is a modest but instructive Linux-kernel fix in the RDMA stack: upstream maintainers silenced an oversized kvmalloc() warning in RDMA/core by adding a no-warn allocation flag, and Microsoft’s initial public mapping names Azure Linux as a product that “includes this open‑source library and is therefore potentially affected.” That vendor statement is authoritative for Azure Linux — but it does not mean Azure Linux is the only Microsoft product that could contain the implicated kernel code. In practice, other Microsoft-distributed kernels and images can — depending on build choices and configuration — carry the same upstream component, and defenders should treat the MSRC attestation as product‑scoped evidence, not categorical exclusivity.

---

Background / Overview​

CVE-2025-37867, tracked in public vulnerability databases, describes a condition where syzkaller (a kernel fuzzing tool) triggered an oversized kvmalloc() warning in the RDMA/core paths; the upstream patch prevents noisy warnings by using the __GFP_NOWARN flag for the allocation. The technical impact is described as a warning that could be surfaced during fuzzing and, in some contexts, could point at memory-allocation sizing issues that affect RDMA operations; most downstream vendors treated the fix as a stability/availability hardening rather than a remote-exploit primitive.
Microsoft’s public security record for this CVE (the MSRC update guide activity and accompanying machine-readable attestation work) takes a deliberately conservative, discoverable stance: Microsoft inspected a class of its Linux artifacts and reported that Azure Linux includes the implicated open-source component and is therefore potentially affected, and also said it will publish CSAF/VEX attestations and expand the product mapping when further Microsoft products are identified as carriers. That process shift — the publishing of machine‑readable VEX/CSAF files beginning in October 2025 — is designed to make these product-by-product attestations explicit and queryable. (msrc.microsoft.com)
Two immediate questions follow for defenders and operators:

• What exactly does Microsoft mean by “includes this open‑source library”?
• Is Azure Linux the only Microsoft product that includes the vulnerable code?

Answering those requires understanding kernel packaging, build-time choices, and how Microsoft manages multiple Linux artifacts (Azure Linux, WSL2 kernels, Marketplace/VM images, linux-azure kernels, etc.).

---

What Microsoft’s wording actually says — and what it doesn’t​

Product-scoped attestation, not exclusivity​

Microsoft’s line — “Azure Linux includes this open‑source library and is therefore potentially affected” — is an explicit, narrowly scoped inventory result. It confirms that the Azure Linux family (Microsoft’s cloud-focused Linux distribution lineage) has the implicated upstream code in the specific artifacts Microsoft inspected. Microsoft has committed to publish VEX/CSAF attestations and to update CVE mappings if additional Microsoft products are discovered to ship the same upstream component. That combination is transparency by design: it tells customers what Microsoft has verified while leaving room to expand the mapping as inventory work continues.
Crucially, that phrasing is not a declarative statement that no other Microsoft product contains the same code. In practice, the presence or absence of an upstream kernel source file — and the exact commit range where the bug was introduced or fixed — is an artifact-specific property tied to:

• kernel version and patch set used to build the artifact,
• kernel configuration flags enabled at build time (which drivers and subsystems were built in or as modules),
• distribution packaging choices and backports,
• and whether the artifact is a full kernel image, a minimal image, or a vendor-tuned kernel for a particular product line.

Put plainly: Azure Linux is the only Microsoft product Microsoft has publicly attested so far for CVE‑2025‑37867, but that is an attestation of what Microsoft has checked, not a global exclusivity guarantee. Security practitioners should treat the attestation as a signal for immediate action on Azure Linux images and as a prompt to verify other Microsoft-distributed kernels in their environment.

---

How other Microsoft artifacts can still carry the same upstream code​

Kernel lineage in the Microsoft ecosystem​

Microsoft distributes multiple Linux kernel artifacts, each with different build and packaging choices:

• Azure Linux (the Azure-distributed, cloud‑tuned kernel family) — this is the artifact Microsoft explicitly attested for the CVE.
• WSL2 kernel builds (the kernel Microsoft publishes for Windows Subsystem for Linux) — these are separate builds, maintained in a public Microsoft GitHub repository and packaged for Windows customers.
• linux-azure / Marketplace images / VM kernel images used to boot virtual machines and marketplace marketplace images; some of these are derived from the same upstream trees but have diverging patch sets.
• Vendor or partner kernel builds that Microsoft consumes or distributes as part of specialized offerings.

Because each artifact selects a kernel version and a set of drivers/modules at build time, the same upstream file or driver (for example, RDMA core or the mlx5 family) can appear in multiple artifacts. Evidence from published WSL2 kernel module lists shows that Microsoft’s WSL2 kernels include RDMA/infiniband modules and related networking components in certain builds, which demonstrates that the RDMA stack is present in at least some Microsoft-maintained kernel images beyond Azure Linux. That means the underlying upstream component that triggered CVE-2025-37867 can appear in other Microsoft kernels — whether it is vulnerable depends on kernel version and the presence (or absence) of the specific fix.

Why presence is conditional (the three technical gates)​

• Kernel version/commit range — The upstream fix for this CVE landed at specific commits and release lines; only kernels built from or after the fixing commit (or with an equivalent downstream backport) are remedied. A Microsoft artifact built from an older base could lack the fix and therefore be in-scope.
• Build configuration (Kconfig) — Many kernel features (including RDMA families and vendor drivers) are optional at build-time. If a kernel build omits the RDMA code, that artifact is not affected even if other Microsoft kernels are. Conversely, a build with RDMA enabled will surface the RDMA/core paths and could be affected.
• Backporting and vendor patches — Distributors comor apply vendor-specific patches. An artifact can include the upstream file but contain a vendor backport that neutralizes the issue, or it could omit the backport and remain vulnerable.

Because these gates are artifact-specific, the correct operational stance is verify and inventory each Microsoft-distributed kernel you run, rather than assuming Microsoft’s Azure Linux attestation covers all Microsoft kernels.

---

Practical implications for operators and security teams​

Short, actionable guidance​

• If you run Azure Linux images: treat the MSRC attestation as an authoritative in-scope finding. Prioritize applying the vendor-supplied update or the upstream patch backport that includes the __GFP_NOWARN change. The VEX/CSAF attestation mechanism Microsoft now publishes will help automate this verification once VEX entries are consumed. (msrc.microsoft.com)
• If you run other Microsoft-distributed kernels (WSL2, linux-azure, Marketplace images, custom Microsoft images): don’t assume safety. Inventory the kernel version and the presence of RDMA modules; if RDMA/IB (infiniband) modules like mlx5 or ib_core are present and the kernel predates the fix, consider those artifacts potentially affected until verified. Public WSL2 module listings show RDMA/infiniband modules exist in WSL2 builds, so verification is required.
• If you run vendor kernels or third-party images in Azure: verify kernel contents. A marketplace image derived from a vendor distribution may include RDMA drivers even if Microsoft’s attestation currently lists only Azure Linux.

A short verification checklist you can adopt now​

• Identify all Linux kernel artifacts running in your environment (Azure VMs, WSL2 users, Azure Arc Linux machines, custom VM images).
• For each artifact, capture:
• kernel version (uname -r),
• kernel build stamp/commit if available (from /proc/ver metadata),
• presence of RDMA and IB modules (lsmod, modinfo, or check /lib/modules/<version>/kernel/drivers/infiniband/).
• Compare kernel versions/commits against the upstream commit that landed the CVE fix. If you cannot determine the commit, treat artifacts predating May 2025 as suspect until verified.
• Apply vendor patches or upstream backports per your distribution’s guidance. For Azure Linux, follow Microsoft's update guidance and VEX attestations.

This checklist aligns with the operational reality that Microsoft’s MSRC mapping is a helpful signal — but artifact-level verification closes the loop.

---

Why Microsoft’s VEX/CSAF rollout matters (and where it helps)​

Microsoft’s move to publish CSAF/VEX attestations beginning in October 2025 is an important transparency milestone. VEX files let vendors say, in a machine-readable way, whether a product is:

• Not affected
• Under Investigation
• Known Affected
• Fixed

For enterprise automation, that matters: security toolchains can read VEX/CSAF records and avoid noisy alerts for products that are not affected while prioritizing confirmed carriers. Microsoft has explicitly started with Azure Linux as the first product to receive this level of machine-readable detail, and it has promised to expand the coverage to additional product families. That approach reduces ambiguity for defenders — but only to the degree Microsoft completes inventories for its entire product catalogue. Until those inventories and VEX attestations are comprehensive, defenders must do artifact-level checks.

---

Technical analysis: what the RDMA/core change actually does​

The fix in brief​

Upstream developers responded to syzkaller’s finding by adding __GFP_NOWARN to the kvmalloc() call site in the RDMA/core path. That flag suppresses a kernel warning on oversized allocation attempts; it is a defensive adjustment that avoids spurious noisy WARNs in fuzzing or unusual allocation paths. The change is not a semantic security hardening that closes a privilege-escalation or remote code execution vector; it is instead a stability/robustness improvement that removes noisy warnings and reduces false positives during fuzz-driven testing. Multiple OEM and distro databases characterize the CVE as a moderate, availability- or reliability-focused item.

Operational impact​

• Exploitability: There is no public proof-of-exploit demonstrating remote code execution derived from this exact warning. The upstream correction addresses a warning and potential allocation handling that could surface under fuzzing or stress conditions.
• Availability risk: Systems heavily exercising RDMA paths (e.g., HPC clusters, storage targets using RDMA, or specialized networking appliances) may encounter noisy WARNs or stability problems if the buggy code path is present and exercised.
• Detection: syslog/kernel logs containing the __kvmalloc_node_noprof WARN trace are the clearest detection artifact. Fuzz test suites and stress tools are most likely to reproduce the condition.

While the CVE’s technical severity is moderate, operators should weigh the exposure in context: RDMA-dependent workloads are more likely to be impacted than general-purpose virtual machines that do not load RDMA modules.

---

Strengths and weaknesses of Microsoft’s current disclosure approach​

Strengths​

• Rapid, product-focused attestation: By mapping an upstream CVEAzure Linux) quickly, Microsoft gives a clear remediation priority to customers that run that product.
• Machine-readable VEX/CSAF push: Publishing VEX entries makes it easier to automate product‑level vulnerability triage and reduces the noise for defenders who run other Microsoft products that may not be affected. Microsoft’s new transparency program is a material improvement over opaque advisories.

Risks and gaps​

• Attestation incompleteness window: There is a period between an initial attesive inventory coverage across all Microsoft artifacts; during that window, other Microsoft kernels (WSL2, linux-azure, Marketplace kernels) might still contain the vulnerable code but be unlisted. The attestation therefore can give a false sense of exclusivity to observers who interpret the one-line advisory too broadly.
• Artifact heterogeneity: Microsoft distributes and supports many kernel images with different patch levels. Without artifact-level metadata (build commits, exact config choices) published alongside VEX, customers must still do manual verification to be certain. The VEX rollout helps but does not remove the need for verification until it reaches comprehensive coverage.
• Communication nuance: Short advisory text can be misread. The phrase “includes this open‑source library and is therefore potentially affected” is precise but terse; organizations need explicit machine-readable attestations and actionable build metadata to make binary decisions for automated remediation pipelines.

---

Recommended next steps for defenders (practical runbook)​

• Treat Azure Linux as in-scope now.
• Apply the vendor update Microsoft publishes for Azure Linux that contains the upstream fix; consume Microsoft’s VEX/CSAF assertions to automate detection for Azure Linux images once VEX entries are available. (msrc.microsoft.com)
• Inventory all Microsoft-distributed kernel artifacts in your environment.
• Identify WSL2 users, Azure VM images, Marketplace images, and linux-azure artifacts. For each, collect uname -r, /proc/version, and module lists (look for infiniband/rdma drivers such as mlx5, ib_core, ib_uverbs). If RDMA modules are present and the kernel predates the fix, escalate.
• Automate VEX/CSAF consumption.
• Integrate Microsoft’s CSAF/VEX feedity management pipeline so product mappings and exploitability assertions are machine-readable and updatable without manual parsing. Microsoft’s blog announcing VEX availability outlines this approach.
• Prioritize workloads that use RDMA.
• For hosts that actually run RDMA endpoints (HPC, NVMe-oF, Infiniband clusters), prioritize patching and schedule maintenance windows to apply updates, because those workloads have higher exposure.
• If in doubt, verify upstream commit presence.
• If you can access build metadata or the kernel source embedded in an artifact, check for the upstream commit that contains the __GFP_NOWARN addition. If you cannot confirm, handle the artifact as potentially affected until verification.

---

A cautionary note on “is it only Azure Linux?” — the short, operational answer​

• Strictly speaking: Azure Linux is the only Microsoft product Microsoft has publicly attested as including the implicated open-source component for CVE‑2025‑37867 at the time of the advisory; Microsoft said it will update the CVE mapping if additional products are found to ship the same code. That statement is an authoritative, product-level attestation for Azure Linux.
• Practically speaking: No, Azure Linux is not necessarily the only Microsoft artifact that could include the vulnerable RDMA/core code. Other Microsoft kernel builds — notably WSL2 kernels and some Azure image kernels — have been shown to include RDMA/infiniband modules in certain builds. Whether a given Microsoft artifact is affected depends on its kernel version, configuration, and whether the upstream fix has been applied or backported. Therefore, defenders must verify each artifact rather than assume Microsoft’s attestation implies exclusivity.

---

Conclusion​

CVE-2025-37867 is an upstream Linux-kernel RDMA/core hardening that removes noisy kvmalloc() warnings by adding a no-warn allocation flag. Microsoft’s public advisory that “Azure Linux includes this open-source library and is therefore potentially affected” is an important, authoritative attestation for Azure Linux and a signpost to customers to patch those images promptly. However, that single-line mapping is a product‑scoped inventory statement, not a guarantee that no other Microsoft product includes the same upstream code. Microsoft’s rollout of machine-readable CSAF/VEX attestations (started October 2025) will make further product mappings explicit over time, but until Microsoft completes inventory and maps every Microsoft-distributed kernel artifact, security teams should inventory and verify the kernel artifacts they run (WSL2, linux-azure, marketplace images, and others) and prioritize patching where RDMA code is present. Treat Azure Linux as a confirmed in-scope product, and treat other Microsoft kernels as unverified until proven otherwise — and plan remediation workflows accordingly.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center