CVE-2025-37772 RDMA CMA: Azure Linux Attestation and Verification Guide

The Linux kernel CVE tracked as CVE-2025-37772 is a targeted fix to the RDMA Connection Manager (CMA) code that prevents a race which can corrupt a work_struct and trigger a kernel NULL-pointer crash. Microsoft’s public advisory for this CVE calls out Azure Linux as a product that “includes this open‑source library and is therefore potentially affected,” and notes Microsoft will expand its published attestations (CSAF/VEX) if additional Microsoft products are identified that ship the same upstream code. That wording is accurate but deliberately scoped — it does not prove that other Microsoft products are safe, only that Azure Linux is the one Microsoft has publicly mapped to the CVE at the time of the advisory. In practical terms: Azure Linux is the only Microsoft product Microsoft has attested (so far) to include the affected code, but it is not technically or logically the only Microsoft place that could ship that upstream RDMA/CMA code. This article explains why, how to check other Microsoft artifacts (WSL, Azure VM images, AKS/VM agent kernels, custom kernel builds), and gives actionable detection and mitigation steps for administrators and engineering teams who run Microsoft-supplied Linux kernels or kernel-based artifacts.

Background / Overview​

CVE-2025-37772 is a medium-severity kernel availability bug in the RDMA/cma subsystem. The root cause is a race: the struct rdma_cm_id contains an embedded work_struct (net_work) that was being re-initialized in the network-event callback. If two network events for the same rdma_cm_id occur in rapid succession, the second INIT_WORK can overwrite the earlier queued work item before it runs, corrupting the work_struct and causing the worker thread to dereference invalid pointers — a classic kernel NULL-pointer crash and denial-of-service.
Upstream kernel maintainers fixed the issue by moving INIT_WORK to the object-creation path so the work_struct is initialized once, preventing the concurrent INIT/queue race. Linux distributions and downstream kernel maintainers have issued patches and updated kernels; Linux vendors (distribution security trackers and downstream advisories) mark the vulnerability as addressed in patched kernel builds.
Microsoft’s public advisory language is conservative: it confirms Azure Linux ships the affected component and that Microsoft will update attestations and CVE mappings if further Microsoft artifacts are discovered to contain the same upstream code. That policy is transparent and aligns with modern vendor vulnerability-tracking practice: attest what you’ve inspected, then expand the list as further inventory checks are completed.

---

Why Microsoft’s statement doesn’t mean “only Azure Linux is affected”​

Short answer: the MSRC FAQ text names Azure Linux because that is the Microsoft product the company has inspected and mapped to the upstream CVE. It is not a technical guarantee other Microsoft artifacts are clean.
Key reasons why the attestation is scoped rather than exclusive:

• Linux kernel source is reused. Microsoft, like many vendors, builds multiple kernel artifacts from upstream Linux sources: Azure Linux kernels for cloud images, the WSL2 kernel that ships in Windows, custom kernel builds for specialized Azure VM images and appliances, and kernels that run inside managed node images (AKS, Azure Stack HCI nodes, etc.). Whether a given Microsoft artifact includes the vulnerable code depends on:
• the upstream kernel version used to build that artifact,
• whether the relevant drivers/subsystems (drivers/infiniband/core/cma.c and related files) were included in the build tree, and
• kernel configuration (CONFIG_ options) chosen at build time.
• Microsoft’s attestations are artifact-level. An attestation for the “Azure Linux” family covers the builds Microsoft inspected for that family — it does not automatically extend to a different product that uses a different kernel branch or a different build configuration.
• Inventory and build-provenance checks take time. Microsoft’s phrasing that it will update the CVE if impact to additional products is identified is standard: vendors publish attestations in phases as they complete inventory mapping across hundreds or thousands of product artifacts.

Consequence: do not treat the Azure Linux attestation as proof that other Microsoft-supplied kernels are unaffected. If you run any Microsoft-provided Linux kernel (including WSL2, Azure Marketplace images, AKS node images, or specialized VMs), you should verify whether that specific artifact includes the RDMA/CMA code and whether it has been patched.

---

Microsoft artifacts that commonly include Linux kernel code (and therefore merit verification)​

Microsoft distributes or maintains several Linux-kernel-based artifacts. Any of the following can — depending on branch and config — include drivers/infiniband and the RDMA/CMA code:

• Azure Linux images (the attested family).
• The WSL2 kernel shipped with Windows (source available publicly in Microsoft’s WSL2-Linux-Kernel repository and distributed as a signed kernel binary inside Windows).
• Azure Marketplace VM images and the kernel they include.
• Azure Kubernetes Service (AKS) node OS images and node kernels (some managed node types use specific kernel builds).
• Azure appliance or platform components that include Linux-based subsystems (for example, certain specialized infrastructure components).
• Any Microsoft-provided virtual machine images where the kernel is derived from upstream Linux trees (sometimes used for performance or driver support).
• Microsoft’s custom kernel builds for specific hardware or scenarios (e.g., GPU cloud images, HPC node images).

Each artifact is a separate build and must be checked independently. The presence or absence of the vulnerable code is not inferred from a different product’s attestation.

---

How to determine whether a given Microsoft-supplied artifact is affected​

If you are responsible for systems running Microsoft-supplied kernels (Azure VMs, AKS nodes, WSL2 instances on Windows devices, marketplace images), use the following pragmatic checks.

1) Identify the kernel version and build metadata​

Run these commands on the target system:

• Confirm the running kernel release:
• uname -r
• Show distribution kernel package version where available:
• On Debian/Ubuntu: apt policy linux-image-$(uname -r) (or dpkg -s linux-image-$(uname -r))
• On RHEL/CentOS/SUSE: rpm -q --qf '%{VERSION}-%{RELEASE}\n' kernel
• On systems that preserve kernel config, check:
• zcat /proc/config.gz | grep RDMA
• or cat /boot/config-$(uname -r) | grep RDMA

Why: CVE inclusion is a function of upstream version and CONFIG_ choices. If the kernel was built without the RDMA/CMA facilities, the code won’t be present even if the version is in a vulnerable range.

2) Search modules and symbol tables for RDMA/CMA artifacts​

On Linux systems check for RDMA-related modules:

• lsmod | egrep 'rdma|ib_'
• ls /lib/modules/$(uname -r)/kernel/drivers/infiniband || ls /lib/modules/$(uname -r)/kernel/drivers/infiniband/core
• modinfo rdma_cm (if the module is present)
• grep -R "rdma_cm_id" /lib/modules/$(uname -r) 2>/dev/null || find /lib/modules/$(uname -r) -type f -exec strings {} \; | grep -F "rdma_cm_id" -m1

If rdma_cm, rdma_ucm, or related modules are present (either built as modules or as built-in symbols), the runtime contains the affected subsystem unless it was patched.

3) Inspect kernel source or distributed kernel packages (where possible)​

If you have the kernel source used to build the artifact, inspect:

• presence of drivers/infiniband/core/cma.c and related files
• the commit range or patchset applied to that tree (look for the applied patch that moves INIT_WORK into object creation)

If you do not have the full source, documented MSI/VEX/CSAF attestations from the vendor are the next-best authoritative source — Microsoft’s attestation for Azure Linux confirms the component was present in that family; absence of an attestation for another Microsoft artifact is not proof it’s absent.

4) For WSL2: check the WSL kernel configuration and modules​

WSL2 ships a Microsoft-supplied kernel binary and the corresponding source is public in the Microsoft WSL2-Linux-Kernel repository. To verify:

• Inspect the published WSL2 kernel configuration (Microsoft includes a config-wsl file in the repository) to see whether INFIBAND/RDMA/CMA support was enabled in that kernel configuration.
• On the Windows host, if you’re using a custom kernel, examine the kernel binary and the included modules VHDX (the default WSL2 kernel includes a modules VHDX or baked-in modules).

If the WSL2 kernel configuration includes INFIBAND or RDMA options and the kernel version used predates the upstream fix, WSL2 could be vulnerable until Microsoft updates or backports the fix.

---

Practical detection: example commands and what to look for​

• Check kernel version:
• uname -r
• Check kernel config for RDMA/CMA:
• zcat /proc/config.gz | egrep 'RDMA|INFINIBAND|CMA' || cat /boot/config-$(uname -r) | egrep 'RDMA|INFINIBAND|CMA'

Look for config settings such as:

• CONFIG_RDMA_CORE
• CONFIG_INFINIBAND
• CONFIG_RDMA_CM
• CONFIG_RDMA_UCMA
  If these are set to y or m, the RDMA/CMA subsystem is compiled in or available as modules.
• Check for modules:
• lsmod | egrep -i 'rdma|ib_'
• find /lib/modules/$(uname -r) -type f -path '/drivers/infiniband/' -print
• If you find rdma modules, check their timestamps and vendor / package provenance to decide whether they are patched.

---

Mitigation and remediation options​

If you determine a Microsoft-provided artifact is running a vulnerable kernel image (includes RDMA/CMA and the kernel predates the patch), apply one or more of these mitigation steps depending on risk tolerance and operational constraints.

Immediate operational mitigations​

• If RDMA/CMA support is not required for your workload, disable the RDMA/CMA modules until you can apply a patched kernel:
• If built as modules:
• modprobe -r rdma_cm rdma_ucm rdma_ucma rdma_core (unload dependent modules carefully)
• Add a blacklist to /etc/modprobe.d/blacklist-rdma.conf to prevent module loading after reboot.
• If built-in (CONFIG_...=y), you cannot unload — skip to patched kernel or vendor-supplied update.
• On cloud VMs, you can change VM image type to one with a patched kernel or apply Azure-provided kernel updates where available.
• For WSL2 users on Windows, switch to a Microsoft-updated WSL kernel release (or point to a patched custom kernel) when Microsoft publishes a patched WSL2 kernel update.

Apply vendor patches / kernel updates​

• Upgrade to a vendor-supplied kernel that contains the fix. Distribution maintainers and cloud vendors published patched kernels (check your OS vendor advisory and apply the update through the standard package manager).
• For Azure Linux customers, accept the Azure Linux updates as they are published — Microsoft has attested Azure Linux and will make security patches available.
• For WSL2 or Microsoft-distributed kernels, wait for or apply the Microsoft update — monitor Microsoft’s security advisories and WSL release announcements.

Verify after remediation​

• Re-check the kernel version and config to confirm the patched kernel is in use.
• Confirm the problematic behavior (NULL-pointer crash) no longer reproduces under previously triggering conditions in a controlled test environment.

---

Risk analysis: who is actually exposed and how severe is the threat?​

Technical exposure profile:

• The vulnerability is local (can be triggered by operations that cause frequent rdma_cm network events for the same rdma_cm_id). It is not a remote code execution bug in the commonly measured sense; exploitability is limited and the principal impact is denial of service via kernel crash or hang.
• Environments that commonly use RDMA stacks (HPC clusters, storage nodes, high-performance messaging fabrics, and some specialized storage or RDMA-over-Converged Ethernet setups) are most likely to exercise the CMA code and therefore are the highest risk.
• Systems that do not load RDMA/infiniband modules (typical general-purpose cloud VMs without RDMA NICs or RDMA-enabled drivers) may not be affected even on older kernels because the code may not be present or enabled.

Operational risk considerations for Microsoft-supplied artifacts:

• Azure Linux images: Microsoft has attested these images and will provide patched updates; customers using Azure Linux images should apply Microsoft updates.
• WSL2: many Windows developers and users run WSL2; if the WSL2 kernel build includes RDMA support and uses an upstream version prior to the fix, there is potential exposure — but WSL2 instances typically run user workloads that are unlikely to exercise RDMA unless intentionally used for HPC/cluster-like workloads.
• Azure Marketplace/AKS images: these are separate builds and must be checked individually. Managed Kubernetes nodes with vendor kernels may be subject to the vulnerability if RDMA is enabled by kernel config or by included modules.

Real-world threat: The vulnerability is primarily an availability issue rather than an integrity or confidentiality issue. There is limited public evidence of exploitation in the wild. However, kernel crashes in production servers can cause service outages, data corruption risk depending on workload and storage stack, or cascading failures if crash-restart cycles occur.

---

Recommended action plan for administrators and platform owners​

• Inventory:
• Produce a list of Microsoft-supplied images and kernel artifacts in use (Azure Linux family VMs, AKS node images, WSL2 on corporate endpoints, Marketplace images).
• For each artifact, record kernel version, build metadata, and whether INFIBAND/RDMA is enabled.
• Rapid detection:
• Run the detection commands (kernel config and module checks) across your fleet using automation (Ansible, cloud-init scripts, or centralized asset management).
• Flag hosts that report RDMA modules or a kernel version in the upstream vulnerable range.
• Prioritize:
• Rank hosts by exposure (HPC/storage nodes first, general-purpose VMs second, developer WSL2 endpoints last).
• Prioritize production infrastructure that uses RDMA-capable hardware.
• Remediate:
• Where possible, apply vendor-provided patches/kernels immediately.
• If patches are not available or operations constraints prevent immediate upgrade, disable RDMA modules until patching is possible.
• For WSL2 endpoints, apply the WSL2 update once Microsoft publishes the patched kernel or configure WSL to use a patched custom kernel if you control the endpoint.
• Validate:
• After remediation, verify kernel versions, confirm modules are up-to-date, and test typical workloads that previously triggered the issue.
• Communicate:
• Document the mitigation steps taken and communicate risks and timelines to stakeholders (DevOps, Site Reliability, and security teams).
• Monitor Microsoft’s published CSAF/VEX attestations for updates expanding the list of affected artifacts.

---

Special notes about vendor attestations and CSAF/VEX​

Microsoft’s move to publish machine-readable attestations (CSAF/VEX) improves transparency: those artifacts show which Microsoft product artifacts have been inspected and mapped to specific CVEs. However, two important caveats:

• A published attestation is a positive confirmation for that artifact; absence of an attestation for another product is not proof of absence of the vulnerable code. Vendors often complete attestations in phases.
• CSAF/VEX is useful for automating impact assessment, but you still need to verify artifact-level details (kernel configuration and exact commit ranges) for any product that matters to your environment.

In short: use Microsoft’s CSAF/VEX attestations as authoritative when they exist, but continue to perform your own artifact-level verification for Microsoft-provided kernels you depend on.

---

Practical examples: “what I would run” (concise checklist)​

• On every Linux VM (including those from Microsoft images) run:
• uname -r
• zcat /proc/config.gz | egrep -i 'rdma|infiniband|cma' || cat /boot/config-$(uname -r) | egrep -i 'rdma|infiniband|cma'
• lsmod | egrep -i 'rdma|ib_|infiniband'
• find /lib/modules/$(uname -r)/kernel -type d -name 'infiniband' -print
• On Windows endpoints using WSL2:
• wsl --status (see Kernel version line)
• If possible, run inside the WSL2 instance:
• uname -r ; zcat /proc/config.gz | egrep -i 'rdma|infiniband|cma'
• If WSL2 kernel contains INFIBAND/RDMA support and the version predates the upstream fix, schedule an update or use a patched custom kernel.
• For Azure/AKS/E2E platform owners:
• Query your image inventory and map each image to the kernel release in use.
• For images that map to vulnerable upstream versions and include RDMA, escalate to patching windows or replacement images.

---

Final technical caveat and recommended reading for kernel engineers​

• The vulnerability is a race in object initialization + workqueue queuing semantics. The upstream fix (moving INIT_WORK to creation path) is standard kernel engineering practice to avoid INIT/queue races. If you maintain custom kernel patches or backports, ensure your backport implements the same logic carefully: the worker queue must never see an uninitialized or overwritten work_struct.
• If you maintain bespoke kernels (for example, tuned Azure Marketplace images, or custom WSL2 kernels used by a fleet), ensure code provenance controls: record exact upstream commit ranges, applied patches, and configuration flags. That will speed vulnerability mapping and attestation for your artifacts in future CVEs.

---

Conclusion​

Microsoft’s public advisory that Azure Linux includes the affected open-source library is a definitive attestation for that product family — but it is not a universal guarantee other Microsoft-supplied kernel artifacts are unaffected. Because Microsoft builds multiple, separate Linux-kernel artifacts (WSL2 kernel, Marketplace images, AKS node kernels, and more), whether any given Microsoft product contains the vulnerable RDMA/cma code depends on the kernel version and build-time configuration used for that specific artifact. The correct operational response for administrators is to assume nothing and verify each Microsoft-supplied kernel artifact you run: inspect the kernel version and config, search for RDMA/infiniband modules, and apply vendor patches or disable RDMA modules when practical. Microsoft’s CSAF/VEX attestations are helpful and should be monitored for updates, but they are one piece of the artifact-level verification you must perform to confidently reduce risk in your environment.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center