Azure Linux CVE-2025-37883: What Microsoft Attested and What It Means

Microsoft’s short public attestation that “Azure Linux includes this open‑source library and is therefore potentially affected” is accurate — but it is a product‑scoped inventory statement, not proof that no other Microsoft product could include the same vulnerable Linux kernel code. In plain language: Azure Linux is the only Microsoft product Microsoft has publicly confirmed as carrying the upstream component implicated by CVE‑2025‑37883, but the technical realities of kernel source, builds, and configuration mean other Microsoft artifacts could theoretically be in scope until they are checked and attested as well.

Background / overview​

CVE‑2025‑37883 is a Linux kernel bug disclosed publicly on May 9, 2025. The fix sits in the s390 architecture tree and addresses an unchecked return from get_zeroed_page() in the SCLP console initialization path (sclp_console_init()). The defect could cause a null pointer dereference (kernel crash / DoS) and was accompanied by a small memory‑leak fix to free repeatedly allocated pages. Upstream kernel maintainers merged defensive checks and a helper to clean up the loop allocation; distribution vendors have mapped those fixes into their kernel updates for affected version ranges.
Two technical facts are important up front:

• The code touched by the patch is in the s390 architecture area of the kernel (IBM Z / mainframe platform); that makes the fix architecture‑specific.
• The vulnerability is a robustness issue (null check and leak), not a remote privilege‑escalation exploit. It’s most likely to be triggered by local actions that touch the SCLP console driver.

Those two facts drive the practical answer to the log‑level question that follows.

---

What Microsoft actually said — and what that wording means​

Microsoft’s public statement about this CVE is concise: Microsoft inspected its artifacts and published an attestation that Azure Linux includes the implicated open‑source component and is therefore potentially affected. Microsoft also stated its intent to publish machine‑readable CSAF/VEX attestations (the VEX rollout began in October 2025) and to update those mappings if additional Microsoft products are later found to include the same upstream component.
How to read that carefully:

• The attestation is product‑scoped. It confirms Microsoft has inventoried Azure Linux and found the vulnerable upstream component in that product’s artifacts.
• It is authoritative for Azure Linux — if you run Azure Linux, treat the attestation as a clear instruction to apply the vendor updates.
• The wording is not a categorical exclusivity statement. It does not assert that no other Microsoft product or artifact contains the same upstream code. Microsoft explicitly said it will update the CVE mapping if more products are found to include the same code.

In short: the attestation identifies a confirmed carrier (Azure Linux) and promises to expand visibility, but it does not prove absence of the component elsewhere.

---

The technical reality: source vs. build vs. runtime​

To understand why Microsoft’s attestation does not imply exclusivity, you need to separate three distinct layers of how open‑source kernel code travels through a vendor’s supply chain:

• Source code presence: the upstream Linux kernel source tree contains code for many architectures and drivers. That source is the same reference for all downstream vendors.
• Build configuration: whether a given kernel build includes and compiles an architecture‑specific file depends on the kernel configuration (CONFIG_ settings) and target architecture used when building the kernel.
• Shipped artifact: the binary kernel image or modules that a vendor ships are what actually run in customers’ systems; only compiled and enabled files in the binary matter for risk.

For CVE‑2025‑37883 the vulnerable code lives under the s390 architecture tree. That means:

• If a Microsoft artifact ships a kernel binary built for the s390 target or a kernel configuration that enables s390/SCLP code, that artifact could be affected.
• If a Microsoft artifact ships an x86_64 or arm64 kernel build (for example, typical WSL2 kernels and most Azure VM kernels on x86_64/arm64 hosts), the s390 code may be present in source control but will normally not be compiled into those binaries — and therefore is not a practical attack surface for those artifacts.

This is why an attestation limited to Azure Linux tells you what Microsoft has validated so far, but not everything about the company’s entire portfolio of kernel artifacts.

---

Which Microsoft products are realistically in scope?​

Short, actionable answer:

• Azure Linux: confirmed by Microsoft as a product that includes the upstream component — treat it as in‑scope and update kernels per Microsoft’s guidance.
• Other Microsoft products that ship Linux kernel binaries: possibly in scope only if they ship an s390‑built kernel or a kernel build that enabled the s390/SCLP driver. These include items such as specialized kernel images Microsoft publishes, internal images for platform services, or other distribution artifacts. There is no public attestation (yet) for such artifacts.
• WSL2 kernels and standard Windows artifacts: unlikely to be practically affected because WSL2 kernel builds are targeted at x86_64/arm64 hosts; s390 architecture drivers are not normally built in those artifacts. That means a WSL2 kernel distributed for Windows hosts would generally not carry this s390‑specific vulnerability in its runtime binary.

Why that list looks the way it does:

• The s390 code matters on IBM Z systems. If you or your vendor are running Linux on s390 hardware (s390x), you need to be alert; if you aren’t, direct exploitation risk from this specific bug is low because the driver is architecture‑specific.
• Microsoft’s attestation for Azure Linux is meaningful — it confirms that specific set of artifacts includes the implicated upstream code. It does not automatically prove that other Microsoft kernel images are clean.

---

How IT teams should verify exposure (step‑by‑step)​

If you manage systems that could be affected, run these checks. Use exact commands and outputs to reach a deterministic conclusion.

• Confirm the architecture the kernel was built for
• Run: uname -m
• If the result is s390x (or another IBM Z identifier), your kernel is built for the s390 architecture — you must assume potential exposure until patched.
• If the result is x86_64 or aarch64, the kernel is not targeted at s390 hardware; s390‑only code will normally not be active.
• Check whether the SCLP driver or s390 bits are present in the running kernel
• Try: zcat /proc/config.gz | grep -i S390
• Or: grep -i sclp /boot/config-$(uname -r) || zcat /proc/config.gz | grep -i sclp
• Look for CONFIG_S390, CONFIG_S390_SCLP, or similar symbols set to =y or =m. If they are not set, the SCLP subsystem was not enabled in that kernel.
• Inspect the kernel binary/modules for compiled artifacts (optional deeper check)
• Search modules: ls /lib/modules/$(uname -r) | grep -i s390
• If there are no s390 modules installed and no s390 files compiled into the kernel, that further reduces practical exposure.
• Map your kernel version against the published affected ranges
• Vendors and public trackers mapped upstream fixes into version ranges. Check your kernel version (uname -r) and compare it to the patched ranges published by kernels and vendor advisories.
• If you run distribution kernels, consult your vendor’s security advisories for their mapping and updates.
• For Azure Linux customers
• Treat Microsoft’s attestation as authoritative for Azure Linux artifacts. Pull the package/kernel update published for Azure Linux and apply it through the distribution’s standard update mechanism.
• For customers running Microsoft-provided or marketplace images
• If the image is an Azure Marketplace appliance or a Microsoft‑provided kernel image, assume product‑scoped attestations may be incomplete and follow the image’s update guidance or contact Microsoft support for clarifications.

If any of these checks returns positive for s390 builds or enabled SCLP bits, schedule immediate patching per vendor guidance.

---

Remediation and mitigation​

• Patch promptly: apply the kernel updates published by the vendor (Microsoft for Azure Linux; distribution vendors for their kernels). Upstream maintainers merged fixes — your vendor’s packages will include those upstream corrections in patched kernel releases.
• If you cannot patch immediately: restrict access to hosts running s390 kernels and implement strong change control. Because the vulnerability is local‑attack vector in most trackers, limit untrusted local access and privilege escalation opportunities.
• Inventory and attestations: use automated SBOM/VEX/CSAF processing where possible. Microsoft’s move to publish machine‑readable VEX/CSAF data (started October 22, 2025) is helpful here — consume those files in your vulnerability management pipeline to reduce false positives and speed response.
• Verify kernel configuration in CI/CD: ensure your build processes do not accidentally enable architecture‑specific drivers for the wrong platforms.

---

Risk analysis — strengths and shortcomings of Microsoft’s approach​

Strengths

• Transparency for Azure Linux. Microsoft performed an inventory and published a product‑level attestation. That’s a useful, actionable piece of information for customers who run Azure Linux images.
• Machine‑readable attestations. Microsoft’s CSAF/VEX rollout (announced October 22, 2025) is a modern, scalable approach to telling customers which upstream CVEs actually matter for which products.
• Commitment to expand mappings. Microsoft has stated it will update CVE records/VEX attestations if additional Microsoft products are identified as carriers.

Shortcomings and risks

• Attestations are phased, not exhaustive. The current VEX scope started with Azure Linux; absence of attestations for other Microsoft artifacts is not proof that they aren’t affected. Customers who assume “no attestation = safe” may miss exposures.
• Product‑scoped wording can be misunderstood. A short line that names one confirmed product sometimes gets read by downstream teams as a guarantee Microsoft checked everything — which is not the case.
• Complex artifact surface. Microsoft distributes multiple Linux kernel artifacts (kernel packages, WSL2 kernels, Azure VM images, marketplace appliances). Each artifact has its own build and configuration; inventorying all artifacts is nontrivial and takes time.

Practical impact of those shortcomings

• Organizations that rely solely on vendor attestations without doing artifact‑level inventory or configuration checks leave themselves exposed to unrecognized carriers of vulnerable code.
• Conversely, the existence of product attestations like the Azure Linux mapping is valuable: it reduces uncertainty for that product and lets customers act quickly.

---

Special note on WSL2 and other x86/ARM artifacts​

A frequent question: “Does this mean WSL2 or other Microsoft Linux kernels are affected?” Two clarifications:

• The source tree for many Linux kernel repositories contains code for dozens of architectures. That source presence does not equal runtime exposure.
• WSL2 kernels distributed for Windows hosts are built for x86_64 or arm64 hosts and normally do not include s390 architecture code in the runtime kernel image. Practically, that makes an s390‑specific kernel fix irrelevant for typical WSL2 installations.

Therefore: if your environment is WSL2 on a standard Windows host (x86_64/arm64), the practical exposure to this s390‑only issue is extremely unlikely. If, however, Microsoft or a third party ships an s390 target kernel artifact for IBM Z platforms, that artifact would need to be checked and patched.

---

Recommended actions for Microsoft and for customers​

For Microsoft (good practice checklist)

• Continue and accelerate the VEX/CSAF roll‑out across all Microsoft artifacts. Customers benefit when attestations cover all kernel images, WSL kernels, marketplace images, and any platform kernels Microsoft builds.
• Publish per‑artifact kernel configuration metadata (kernel config fragments) alongside kernel binaries so downstream customers can programmatically determine whether a given kernel includes specific drivers or architecture code.
• Where feasible, include kernel ABI and module lists in the SBOM so customers can quickly map CVEs to shipped binaries.

For customers and operators

• Treat Microsoft’s Azure Linux attestation as authoritative for Azure Linux. Patch Azure Linux artifacts promptly when Microsoft publishes fixes.
• Don’t assume absence of an attestation means safe. For other Microsoft artifacts you use (WSL2 kernels, Azure marketplace images), perform the three checks described earlier (uname -m, /proc/config.gz checks, module listings).
• Integrate vendor VEX/CSAF feeds into your vulnerability management tooling and cross‑check those feeds against binary artifact inventories.
• If you run workloads on heterogeneous architectures (including IBM Z / s390x), escalate to platform engineering and ensure all relevant kernel builds are inventoried and patched.

---

Final assessment — concise answer to the user’s question​

No — Azure Linux is the only Microsoft product Microsoft has publicly attested (so far) to include the upstream component implicated by CVE‑2025‑37883, and so it is the product Microsoft has told customers to treat as potentially affected. However, that attestation is a product‑scoped inventory statement, not a technical guarantee that other Microsoft products cannot include the same vulnerable code. The underlying vulnerability is architecture‑specific (s390); therefore other Microsoft artifacts that ship kernels targeted at non‑s390 platforms (for example, standard WSL2 kernels and most x86_64/arm64 Azure VM kernels) are unlikely to be practically affected — but any Microsoft artifact that ships an s390‑built kernel or enabled SCLP code would be in scope and needs verification.
Treat Microsoft’s attestation as authoritative for Azure Linux, run the verification steps I outlined for your other Microsoft artifacts, and demand artifact‑level attestations or kernel config metadata for any Microsoft kernel images you rely on until the VEX roll‑out covers the full portfolio.

---

Conclusion
Microsoft’s product‑level attestation is a positive step toward supply‑chain transparency, but it is only the beginning. Azure Linux customers should act now to apply vendor updates. Other Microsoft customers should not assume they’re automatically out of danger; instead, they should validate the architectures and kernel configs of the Microsoft artifacts they run. Where uncertainty remains, insist on per‑artifact attestations or include artifact verification in your patching and SBOM processes — and push your vendors to expand machine‑readable VEX coverage to close the visibility gap.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center