Azure Linux MSRC Attestation and CVE-2025-37905: Understanding Scope

The short answer is: no — Microsoft’s MSRC attestation naming Azure Linux as “potentially affected” does not prove that Azure Linux is the only Microsoft product that could carry the vulnerable open‑source code. Microsoft’s advisory is an authoritative inventory statement for Azure Linux itself, but it is not a technical guarantee that other Microsoft images, kernels, or artifacts cannot contain the same upstream Linux kernel component. Operators should treat the MSRC attestation as guidance about scope, not as a blanket exclusion of other Microsoft products.

Background / Overview​

CVE‑2025‑37905 is a Linux kernel vulnerability in the firmware/arm_scmi codepath described upstream as “Balance device refcount when destroying devices.” At a high level the problem was an imbalance of device reference counts triggered when the SCMI device lookup and teardown used device_find_child(), which implicitly increments a device reference (a get_device()). That implicit get was not balanced in all teardown paths, which in turn prevented device_release hooks from running and allowed kernel‑side structures to remain unfreed. The practical symptom observed by maintainers and testers was that KMemleak flagged unreferenced kernel objects after loading and unloading certain SCMI drivers.
This problem is primarily a resource‑management/availability issue: it produces memory leaks in the kernel and can lead to reduced stability or availability over time. Public severity assessments placed the issue in the medium range (CVSS mid‑5.x), and the remediation is a small code patch in the SCMI firmware driver that balances refcounts properly. Upstream kernel maintainers merged fixes into the stable branches; most downstream Linux distributors issued security updates or backports.
Microsoft’s public guidance for a number of Linux kernel CVEs — including the wording you quoted — follows a consistent pattern: when the company has inspected particular artifacts and confirmed the presence of an upstream component, MSRC maps that upstream component to the specific Microsoft product (so far, Azure Linux) and notes that Azure Linux “includes this open‑source library and is therefore potentially affected.” Microsoft also announced a rollout of machine‑readable CSAF/VEX attestations for Azure Linux and committed to updating the CVE and attestation records if it discovers additional Microsoft products that ship the same upstream component.

---

Why the MSRC statement matters — and what it does not mean​

What Microsoft is saying​

• The MSRC mapping is an inventory attestation for Azure Linux. Microsoft has inspected Azure Linux artifacts (packages/kernel builds) and confirmed they include the upstream Linux component referenced by the CVE.
• That attestation is authoritative for Azure Linux: if you run Azure Linux images, treat Microsoft’s statement as definitive guidance that the product is in scope for remediation.

What Microsoft is not saying​

• The MSRC wording is not an exhaustive list of every Microsoft product that might contain the same upstream component.
• Saying “Azure Linux includes this open‑source library and is therefore potentially affected” does not implicitly mean that no other Microsoft product includes that library. It simply means Azure Linux has been checked and attested; other artifacts may or may not include the same code and remain unverified until Microsoft updates the mapping or until third parties inspect them.

Put simply: Microsoft has told you which of its products they have checked and attested to. They have not — and practically cannot in one statement — assert that every Microsoft image, kernel, embedded device, or product has been checked in the same way.

---

Why that distinction matters to security teams​

Many enterprises assume that a vendor statement naming one product implies exclusivity — that is, “if vendor X names product A, then our other vendor products are safe.” For modern software ecosystems this is a dangerous assumption.

• Open‑source components are reused in multiple ways across a vendor’s portfolio: packaged distros, cloud VM images, container images, IoT builds, custom kernel builds (for appliances or hypervisors), and more.
• The same upstream code can appear in different binary forms and different kernel configurations; whether a particular commodity includes the vulnerable code depends on the exact kernel commits, build configuration, and whether the ARM‑specific driver is compiled in.
• Vendors are pragmatic about attestation: they usually begin with the product they ship as an official distro (here, Azure Linux) and expand the attestations over time. That process creates a “known affected” list and an “unverified” list; unverified does not mean safe.

For customers this means you must map your own artifacts (VM images, containers, on‑prem appliances, WSL kernels, AKS node images, etc.) to the upstream commits or vendor patch levels rather than relying on a single vendor sentence for a blanket assurance.

---

Technical reality check: scope of the vulnerability​

Targeted code and architecture​

• The CVE is rooted in the arm_scmi firmware driver. The SCMI (System Control and Management Interface) subsystem is an ARM‑centric firmware/firmware‑interface used on many ARM System‑on‑Chip (SoC) platforms to expose power, performance and sensor controls to the OS.
• Because this is an ARM‑targeted driver, the vulnerability is meaningfully relevant only to systems running ARM kernels or kernels compiled with the arm_scmi driver included. x86_64 kernels that do not include the ARM SCMI driver are not affected simply because the codebase is not present or not compiled in for that architecture.

Typical mitigation surface​

• If your infrastructure runs only x86_64 VMs with kernels that were built without ARM firmware drivers, your risk exposure is low.
• If you run ARM‑based VMs or appliances (for example, ARM VM instances, edge devices, Raspberry Pi‑class hardware, ARM‑based cloud hosts), then the arm_scmi component can be present and the vulnerability becomes relevant.
• Many cloud images for ARM (including ARM‑optimized Azure VM images, container base images for ARM, and vendor kernel builds used in IoT appliances) are the places to check.

Observed impact​

• The vulnerability was reported and triaged as causing an unbalanced device refcount, which in turn prevented release callbacks and allowed kernel objects to leak. KMemleak (a kernel memory leak detector) was used to detect the symptomatic leaks.
• The practical risk is memory leakage and availability degradation, not a straightforward remote code execution path. Exploitation models therefore are constrained — the issue is not a network‑facing RCE but a kernel integrity / resource exhaustion problem that requires local privilege in most realistic scenarios.

---

What Microsoft actually attested — and Microsoft’s transparency plan​

Microsoft explicitly explained that:

• Azure Linux includes the upstream open‑source component in question and is therefore potentially affected.
• Microsoft has started publishing machine‑readable CSAF/VEX attestations (the public rollout began in October 2025) to map upstream components to Microsoft products.
• If Microsoft finds additional Microsoft products that ship the same upstream component, the company will update the CVE mapping / VEX records to reflect that.

That phrasing is consistent across multiple MSRC advisories for Linux kernel CVEs: Azure Linux is the product Microsoft has checked and published a VEX for, and Microsoft will expand coverage if other products are found to carry the component.

---

How to determine whether your Microsoft‑supplied artifacts are affected​

Do not assume safety because the CVE page only names Azure Linux. Instead follow a short, repeatable verification process:

• Inventory your artifacts
• List every Microsoft image or product you use that could contain a Linux kernel or Linux userland: Azure Linux images, Azure Marketplace images, Azure Kubernetes Service node images, Azure VM images (Ubuntu, CentOS, RHEL, Azure Linux), Windows Subsystem for Linux (WSL) kernels distributed by Microsoft, Azure Appliance images, and any prebuilt Microsoft virtual appliance you run.
• Identify platform architecture
• Confirm whether those artifacts are ARM/arm64 or x86_64 builds. The arm_scmi vulnerability affects ARM‑centric code; x86_64 builds are less likely to include arm_scmi.
• Map kernel versions and configuration
• For each artifact, get the kernel version and the kernel configuration (CONFIG options) or whether the firmware/arm_scmi module is present. If possible, boot a test instance and inspect /boot/config‑* or the kernel module list to confirm presence.
• Map commits / vendor patch level
• Compare your kernel version or vendor patch level against the stable commits that fixed CVE‑2025‑37905. If your kernel contains the upstream commit that fixes the refcount imbalance, you are patched.
• Check Microsoft’s CSAF/VEX feed and product attestations
• Microsoft’s VEX/CSAF artifacts are authoritative for the products Microsoft has inspected. If you run Azure Linux, the Microsoft attestation is the right place to start. For other Microsoft artifacts, look for incremental VEX updates or Microsoft advisory updates.
• If in doubt, assume in‑scope and patch
• When verification is unclear and the artifact runs on ARM or could include the SCMI driver, prioritize applying the vendor kernel update or the upstream patch.

---

Practical remediation and mitigation steps​

• Update kernels: The correct fix is to install kernel packages that include the upstream refcount patch. Distributors (Debian, Ubuntu, SUSE, etc.) released patches or backports to stable kernels; patching and rebooting nodes is the standard remediation.
• For AWS / Azure / other cloud nodes: Use vendor images and managed patching channels. On Azure, update the VM image or node pool version. For AKS and similar managed services, follow the provider’s security notices and node image updates.
• For appliances and embedded systems: Rebuild and redeploy an updated kernel that contains the fix. If you cannot rebuild immediately, consider temporary mitigations like removing or blacklisting the arm_scmi module — but note that blacklisting may disable platform features and must be validated.
• For WSL and developer images: Check the WSL‑supplied kernel builds (particularly on Windows on ARM) and apply Microsoft’s updates if they ship affected kernels. If you rely on third‑party distro images inside WSL, check the distro’s kernel.
• Logging and monitoring: Watch for KMemleak or kernel memory leak indicators and monitor for repeated device probe/unprobe churn on platforms where SCMI drivers are present.

---

How to map your kernel to the upstream fix (technical checklist)​

• Identify the upstream stable commit(s) that fixed the issue in the kernel tree.
• In your running kernel, check uname -r and the vendor kernel changelog to see whether the commit was included or backported.
• If you have kernel source or a distribution package, search the patch headers or stable commit references for the SCMI refcount fix.
• If you cannot find proof, assume the node is unpatched and schedule an update.

This is the most reliable way to know whether a given binary artifact contains the vulnerability: the presence or absence of the upstream patch in the exact kernel build you run.

---

Specific notes about Microsoft products and likely exposure​

• Azure Linux (attested): Microsoft has explicitly stated this product includes the open‑source component and is potentially affected. If you use Azure Linux, apply Microsoft or Azure vendor updates as released.
• Azure Marketplace images and other distro images on Azure: Marketplace images are often supplied by third parties or by OS vendors — these must be checked individually. Some Azure Marketplace images are maintained by Canonical, Red Hat, SUSE, etc., who publish their own advisories and patches.
• Azure VM images that are standard vendor distros (Ubuntu, Debian, SUSE): these vendor images often include ARM‑specific kernels for ARM‑based VM SKUs; consult the distro advisory (Ubuntu USN, Debian DSA, SUSE advisories) to see if your image includes the patched kernel.
• WSL and Windows on ARM: WSL2 uses a Microsoft‑distributed kernel. On Windows x64 WSL kernels are x86_64 and unlikely to include arm_scmi. On Windows on ARM, kernel builds differ and should be audited if you rely on WSL on ARM devices.
• Cloud services that build custom kernels (for example, specialized Azure marketplace appliances): those artifacts might include the vulnerable code; check vendor attestations and Microsoft VEX records as they become available.

---

Risk assessment — strengths and limitations of Microsoft’s attestation approach​

Strengths​

• Microsoft’s approach of publishing machine‑readable CSAF/VEX attestations is a meaningful step forward for transparency. For customers running Azure Linux, Microsoft provides definitive, machine‑readable inventory and vulnerability‑inclusion statements that accelerate triage and automated patch management.
• The attestation model allows Microsoft to update their mappings as they verify other products — that means the record is living, not static.

Limitations and risks​

• The attestation is initially sparse: starting with Azure Linux is logical but leaves customers running other Microsoft artifacts to perform their own verification.
• The upstream component can be present in many artifacts in different forms. Attestation for one product does not equal exhaustive scanning across an entire vendor portfolio.
• Time lag and patch diverges: vendors sometimes backport, rebase, or carry custom patches. A Microsoft product may ship a kernel with backported fixes that do not match a canonical upstream commit ID, complicating automation that matches by commit hash.
• The architecture nuance matters: arm_scmi affects ARM platforms primarily. Many enterprises could mistakenly treat x86 artifacts as affected when in fact they are not; conversely, ARM‑specialized images or edge devices may be overlooked.

---

Recommended actions for security teams (prioritized)​

• If you run Azure Linux: treat the MSRC attestation as authoritative and apply the vendor updates or recommended kernel upgrades immediately.
• If you run any ARM‑based instances, appliances, or node images from Microsoft or third parties: inventory and map kernel versions and check for the presence of the SCMI driver.
• For any Microsoft artifact not explicitly attested by MSRC: do not assume safe — either verify (kernel version, config, commit mapping) or ask Microsoft for VEX/CSAF confirmation.
• Automate artifact inventory: integrate CSAF/VEX feeds where available into your vulnerability management pipeline so attestation updates automatically inform your remediation workflows.
• Use network segmentation and least‑privilege on systems running ARM workloads to limit exposure to local privilege escalation or kernel instability issues.
• If you cannot patch immediately, consider temporary mitigations such as blacklisting the arm_scmi module on devices where doing so is operationally acceptable.

---

Final analysis and takeaways​

Microsoft’s public wording — “Azure Linux includes this open‑source library and is therefore potentially affected” — is accurate and valuable, but intentionally narrow. It tells you where Microsoft has already completed a product inventory and issued an attestation. It does not prove exclusivity.
For defenders the practical implication is straightforward: use Microsoft’s attestation as a starting point, but perform the artifact mapping and verification that your environment requires. Because the CVE targets ARM firmware code, prioritize ARM‑based systems for investigation. For Azure Linux customers, follow Microsoft’s guidance and update promptly. For other Microsoft images and artifacts, don’t treat the absence of a Microsoft attestation as evidence of safety — treat it as “unverified” until you can confirm otherwise.
Be methodical: inventory artifacts, confirm architectures and kernel builds, map to upstream fixes or vendor advisories, and apply updates. Microsoft’s new CSAF/VEX transparency is a helpful tool in this process, but it’s not a substitute for a defensible, repeatable verification and patching program across your deployed images and services.

---

Conclusion
Azure Linux is the Microsoft product that has been publicly attested as potentially affected by CVE‑2025‑37905, and Microsoft’s CSAF/VEX program will expand that mapping as more artifacts are checked. However, Azure Linux is not necessarily the only Microsoft product that could include the vulnerable arm_scmi code. Security teams must follow the verification steps above — focusing on ARM workloads, kernel versions, and vendor patch levels — to determine actual exposure and to remediate promptly.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center