Microsoft’s Security Response Center has published an advisory for CVE-2025-37905, confirming that Azure Linux is potentially affected by a memory leak in the Linux kernel’s ARM SCMI driver. The advisory, however, does not assert that Azure Linux is the only Microsoft product that carries the flawed code — a nuance that leaves administrators of other Microsoft‑supplied Linux images and kernels on their own to verify exposure.

What Actually Changed: The CVE and Microsoft’s Advisory

CVE-2025-37905 targets a vulnerability in the firmware/arm_scmi codepath of the Linux kernel. Upstream maintainers describe the issue as an imbalance of device reference counts during device teardown. The SCMI (System Control and Management Interface) subsystem uses device_find_child(), which automatically increments a reference counter. In certain error paths, that increment was never balanced with a corresponding put_device(), preventing cleanup routines from freeing kernel memory. The result is a slowly accumulating memory leak that can degrade stability over time, flagged by tools like KMemleak.

The flaw is architecture‑specific: it lives in a driver intended for ARM‑based systems. An x86_64 kernel built without the ARM SCMI driver is unaffected. Public severity assessments place the CVSS score in the mid‑5 range, indicating a medium‑severity availability concern rather than a remote code execution risk.

Microsoft’s advisory, posted on its Security Update Guide, states that Azure Linux “includes this open‑source library and is therefore potentially affected.” This language follows a pattern the company established after it began publishing CSAF/VEX machine‑readable vulnerability attestations in October 2025. The advisory also notes: “If impact to additional products is identified, we will update the CVE to reflect this.” In other words, Microsoft has verified Azure Linux’s exposure and issued a formal attestation, but it has not exhaustively scanned every other product in its portfolio — nor does it claim to have done so.

What This Means for You: Audience‑Specific Impact

For Home Users and Enthusiasts

If you run Windows on an ARM‑based PC (such as a Surface Pro X or a Copilot+ PC) and use Windows Subsystem for Linux 2, you are relying on a Microsoft‑shipped kernel. On ARM devices, that kernel may include the SCMI driver. Similarly, if you experiment with Raspberry Pi‑class hardware running Microsoft‑provided Linux images (like certain IoT offerings), the driver could be present. Check your kernel version and configuration to confirm exposure. A quick terminal command — lsmod | grep arm_scmi or zgrep ARM_SCMI /proc/config.gz — will tell you if the module is loaded or built‑in.

For IT Administrators and DevOps Teams

If you manage Azure VMs that use ARM‑based instance types (e.g., Ampere Altra processors), the CVE is immediately relevant, especially for Azure Linux images. However, do not stop there. Microsoft’s silence on other products — Azure Kubernetes Service (AKS) node images, IoT Edge runtimes, Azure Marketplace Linux offerings, even WSL kernels in enterprise environments — is not a safety guarantee. The same upstream source code can appear in many artifacts, each with its own kernel configuration. Unverified does not mean safe.

Administrators should inventory all Linux systems that originate from Microsoft or that run on Microsoft‑provided kernels. Pay special attention to ARM‑based assets, which are the only ones architecturally capable of loading the vulnerable driver. For x86_64 systems, risk is effectively zero.

For Developers and System Builders

If you derive custom images from Azure Linux or any Microsoft‑supplied kernel tree, your builds may inherit the vulnerable code. Review your kernel configs: the CONFIG_ARM_SCMI_PROTOCOL and related options should be examined. Even if you aren’t targeting an ARM platform, a misconfigured cross‑build could pull in the driver. Validation steps — booting a test instance, inspecting the kernel module list, and cross‑referencing commit IDs — are straightforward and documented below.

How We Got Here: The Vulnerability and Microsoft’s Transparency Push

The bug was discovered during upstream Linux kernel testing. The arm_scmi driver, part of the kernel’s firmware subsystem, handles communication between the OS and ARM‑based System on Chip firmware for power, performance, and sensor management. device_find_child() adds a reference to a device object when locating it; during driver unbind or device removal, the missing put_device() left the object dangling. KMemleak detected the leaked memory after repeatedly loading and unloading SCMI drivers. Upstream maintainers committed a fix (a small refcount‑balancing patch) that flowed into stable kernel branches. Most major Linux distributions have since shipped updates.

Microsoft’s decision to publish CSAF/VEX attestations for Azure Linux was a transparency effort announced in October 2025. For each applicable CVE, the company maps the upstream component to the Azure Linux product and issues a machine‑readable statement of exploitability. In this case, the CVE‑2025-37905 advisory is the result of that process. The explicit note that the record will be updated if other products are affected underscores that the current advisory is an initial finding — not a final, portfolio‑wide declaration.

What to Do Now: Verification and Remediation Steps

If you use Azure Linux, treat the MSRC advisory as authoritative and immediately apply the latest kernel updates from Microsoft. The fix is included in the updated package set delivered through the normal update channel.

For all other Microsoft‑sourced or Microsoft‑hosted Linux deployments, follow this checklist:

  1. Inventory your ARM‑based Linux assets. This includes AKS node pools on ARM, IoT appliances, WSL2 instances on Windows on ARM, Azure Marketplace images for ARM, and any custom images built from Azure Linux.
  2. Check for the SCMI driver. On a running system, run lsmod | grep arm_scmi. If nothing appears, also run zgrep ARM_SCMI /proc/config.gz to see if the driver is built into the kernel rather than loaded as a module. A positive hit means the vulnerable code is present.
  3. Verify the kernel patch level. Once you know the driver is present, check the kernel version. The upstream fix was merged into stable branches with commits bearing messages like “scmi: fix device refcount leak.” Compare your kernel’s changelog (via uname -r and the distribution’s package manager) against the stable tree. If you can’t confirm the fix was applied, assume the system is vulnerable.
  4. Apply updates or mitigate. For patched systems, schedule a reboot. If you cannot patch immediately and the SCMI driver is not critical to your workload (rare on ARM), you can blacklist it by adding blacklist arm_scmi to a file in /etc/modprobe.d/, but test thoroughly: on many ARM platforms, the driver is essential for features like DVFS or sensor monitoring. Blacklisting may degrade or break functionality.
  5. Monitor Microsoft’s VEX feed. Microsoft has committed to updating CVE records if other products are found affected. Subscribe to the CSAF/VEX feed or periodically check the advisory page for new attestations.
  6. For WSL on ARM: Look for kernel updates delivered through Windows Update or the Microsoft Store (depending on your Windows version). After updating, verify the WSL kernel version with wsl.exe --status.

Outlook: Expect Broader Attestations, but Verify for Now

Microsoft’s move toward machine‑readable vulnerability disclosures is a genuine improvement for Azure Linux users. However, the program is young and, by design, starts with the company’s flagship Linux distribution. As ARM‑based cloud workloads grow, expect more products to appear on future VEX records. For now, treat any Microsoft‑supplied Linux artifact that hasn’t been explicitly attested as unverified — and therefore, potentially vulnerable — until you’ve done your own technical checks. The lesson of CVE-2025-37905 is not that Azure Linux is uniquely flawed; it’s that open‑source components demand architecture‑aware inventory practices, especially when vendors are still building out their transparency tooling.