CVE-2025-39694: s390 SCLP Kernel Bug and Azure Linux Impact

A subtle but important flaw in the Linux kernel's s390 SCLP handler — tracked as CVE-2025-39694 — has been fixed upstream, and Microsoft’s security guidance currently identifies Azure Linux as the only Microsoft product known to include the affected kernel component; however, the architecture-specific nature of the bug means the real-world impact across Microsoft’s portfolio is narrow but must be understood carefully by administrators, cloud architects, and security teams.

Background​

The CVE in question — s390/sclp: Fix SCCB present check — was disclosed as a Linux kernel vulnerability that arises from a faulty NULL-address check performed after physical-to-virtual address translation in code invoked by the SCLP (Service Call Logical Processor) interrupt handler. In certain identity-mapping configurations the virtual address produced by the translation can never be zero, bypassing the intended NULL check and risking incorrect accesses to the identity-mapped first page. The Linux stable tree contains commits that correct this by handling the NULL case before translation, and multiple distro vendors and security trackers have published advisories and patches.
This is an architecture-specific issue: the code lives under drivers for the s390 architecture — the Linux kernel port for IBM Z / z Systems (often referenced as s390 or s390x). That means the code path is relevant only for kernels built for, or including support for, the IBM mainframe architecture. The upstream kernel announcement and downstream advisories explicitly describe the affected file as drivers/s390/char/sclp.c, which aligns the defect squarely with IBM Z platform code.

---

Why architecture matters: s390 vs x86/ARM​

Not all Linux kernels are created equal. A single kernel source tree contains drivers for dozens of architectures, but each binary kernel — the one you boot on a given machine or ship in a product — is typically configured only for the target architecture(s) supported by that product. That means:

• Kernels built for x86_64 or ARM64 do not normally include s390-specific drivers. Microsoft’s WSL2 kernel and most Windows-provided kernels target x86_64 and ARM64, and their configuration and source repositories show no s390 tracing or SCLP driver code paths. (github.com)
• Distributions and images that target IBM Z (s390x) do include s390 drivers and are consequently the ones that must be patched when this CVE applies. Vendor advisories from Debian, Red Hat derivatives, and others note fixes and backports specifically for kernels built for s390.

Put simply: the vulnerability exists in code that only runs when a kernel is built with the s390/SCLP support active and then deployed on compatible IBM Z hardware. That limits the range of potentially affected systems, but it does not eliminate the need for vigilance — particularly for cloud images, private clouds, or appliances that intentionally support s390x.

---

What Microsoft has said (and how to read it)​

Microsoft’s security guidance pages for Linux-sourced CVEs have, in multiple entries, included a standard FAQ reply explaining that Azure Linux is the Microsoft product known to include the affected open-source components and that Microsoft will update CVE entries if additional product impacts are discovered. That guidance emphasises two points:

• Microsoft operates an Azure Linux distribution and manages many of the Linux packages and kernel builds used in Azure images, and it treats that distribution as the product most likely to include the vulnerable code paths.
• Microsoft commits to transparency and to publishing machine-readable advisories (CSAF/VEX) for component impact and mitigations, and will revise its product impact statements if further analysis identifies additional Microsoft products that include the affected libraries.

This phrasing is careful and deliberate: Microsoft is not claiming absolute exclusivity, it is stating the current known Microsoft footprint for the component. When a vendor uses “is the only product known to include X,” that generally means they have scanned their product artifacts and landing pages and found the component present in the named product, but not in other shipping artifacts — at least at the time of the advisory. As the MSRC text shows, Microsoft reserves the right to update the CVE entry if more impacts are discovered.

---

Is Azure Linux really the only Microsoft product that includes the affected library?​

Short answer: Based on public advisories and the architecture-specific nature of the vulnerability, yes — Azure Linux is the only Microsoft product publicly identified as including the affected s390 kernel component right now. But that short answer needs context and caveats.
Why that conclusion is reasonable:

• The vulnerability is in the Linux kernel’s s390 SCLP driver. Public upstream announcements and distro advisories confirm the affected file and that patches were applied in the kernel stable branches. Those announcements are not generic “library” issues; they are kernel architecture code issues. If a Microsoft product does not ship a kernel for s390, it won’t include the vulnerable file.
• Microsoft’s WSL2 kernel repository and release notes indicate the WSL kernel is built and maintained for x86_64 and ARM64 target platforms and does not include s390 code paths (a search of the WSL kernel source tree shows no s390/sclp traces or s390x artifacts). That strongly suggests WSL — despite being a Microsoft-distributed Linux kernel — is not affected by this s390-specific CVE. (github.com)
• Major distros and enterprise vendors published s390-targeted advisories (Ubuntu, SUSE, Red Hat derivatives, Debian), which matches the expectation that only s390-enabled kernel builds need the patch. If a Microsoft product does not ship s390-enabled kernels, there is no direct inclusion of the vulnerable code.

Caveats and edge cases you must consider

• Microsoft’s statement is time-bound and may change. It reflects Microsoft’s current inventory scanning and product packaging. If Microsoft subsequently packages or distributes an s390-enabled kernel, or if a Microsoft-managed image in Azure Marketplace is later built for s390 (for example, a vendor-provided image intended for IBM Z instances), the product impact statement could change — and Microsoft commits to updating CVE entries when that happens. Always assume vendor guidance may be updated after initial publication.
• Customer-provided images and third-party marketplace images: Azure hosts many customer and partner images. If a customer or ISV uploads an image built for s390x (unusual in Azure, but possible in heterogeneous cloud setups), Microsoft’s product impact statements about Microsoft-delivered products won’t capture those. Operators must scan and patch their own images.
• Binary appliances or custom devices: Any Microsoft-branded product that bundles an s390-capable kernel would be in-scope. Right now there’s no public evidence of other Microsoft-branded products shipping s390 kernels, but absence of evidence is not evidence of absence — which is why the vendor’s conditional phrasing matters.

---

Verification steps we performed​

To assess the question objectively we cross-checked upstream and downstream sources and Microsoft artifacts:

• Reviewed upstream Linux kernel security announcement and stable branch commits describing the exact file and defect. The kernel CVE announcement gives the developer-level description and the commit references that fix the check in drivers/s390/char/sclp.c.
• Consulted NVD/OSV and multiple distro advisories to confirm that the fix was applied and that downstream vendors treat this as an s390-targeted kernel fix. These trackers list the CVE, give a consistent description, and link to kernel commits and vendor advisories.
• Examined Microsoft’s public CVE guidance pages and archived MSRC advisory text patterns, which consistently use the same FAQ wording to say Azure Linux is the Microsoft product identified as including open-source Linux components that may be affected and will be updated if additional product impacts are found. That wording was present on MSRC advisories in the same release window and aligns with the quote you provided.
• Looked at the Microsoft WSL2 kernel source and release notes to confirm which architectures Microsoft’s WSL kernel is built for and to verify that s390 drivers are not present in Microsoft’s WSL kernel tree. The WSL2 repository and docs center on x86_64 and ARM64 builds and show no s390 driver code in the repo. (github.com)

These cross-checks converge on the same conclusion: the fix is for an s390-specific kernel driver, and Microsoft publicly names Azure Linux as the Microsoft product known to include the affected components.

---

Practical impact for Microsoft customers and admins​

If you operate in a Microsoft environment, here’s how to interpret and act on this CVE:

• Azure Linux customers: Treat this as a real, actionable issue in managed images or kernel packages supplied by Azure Linux. Follow Microsoft’s Azure Linux patch guidance and update affected images promptly when Microsoft publishes the patched kernel or CSAF/VEX data. Microsoft has emphasized ongoing updates and machine-readable advisories for these cases.
• WSL2 users and Windows-only deployments: Unlikely to be affected. WSL2’s kernels are tailored for x86_64/ARM64 and the Microsoft WSL kernel source contains no s390 SCLP code. Standard Windows or WSL installations are not shipping the s390 driver that this CVE targets. Still, if you use custom kernels in WSL or run exotic appliances, verify those builds explicitly. (github.com)
• Azure infrastructure and multi-tenant clouds: Microsoft’s product impact statement pertains to Microsoft-distributed components. If you use third-party images in Azure Marketplace, especially vendor-maintained images that target specialized hardware, verify with the image vendor whether their kernels include s390 support. It’s also a reminder that cloud marketplaces can contain images whose maintainers are not Microsoft; responsibility for patching may rest with the image publisher or the tenant.
• On-prem and hybrid environments: If you or your customers run IBM Z hardware (s390x), the CVE is relevant irrespective of Microsoft. Kernel updates from your chosen distro (RHEL, SLES, Debian, Ubuntu, etc.) should be applied according to vendor advisories. If you’re running Linux on IBM Z but your deployment is managed by Microsoft technology (for example, cross-cloud management), ensure the kernel used on the s390x platform is patched.

---

Recommendations — what to do now​

Follow a prioritized, defensible approach:

• Inventory: Identify which systems you run that use s390x kernels (IBM Z / z Systems). This is an explicit architecture-level check: if uname -m or equivalent shows s390x, the kernel is potentially in-scope. Do not assume all Linux systems are affected.
• Patch Azure Linux images: If you rely on Azure Linux, apply Microsoft’s recommended kernel updates as soon as they are available. Use Microsoft’s CSAF/VEX feeds (where published) or the Azure update channels to automate the fix. Microsoft has stated it will publish these advisories and will update CVE product impact when needed.
• Confirm WSL/custom builds: If you maintain custom Microsoft-supplied kernels (e.g., a bespoke WSL kernel build), validate that s390 drivers are not enabled in the kernel configuration. If you intentionally enabled s390 support for development or cross-compilation scenarios, treat those builds as potentially vulnerable. (github.com)
• Check third-party images: For Azure Marketplace images and third-party or customer-provided VM images, verify the distro vendor’s advisory and kernel patch level — particularly if those images target or include s390x support. Maintain responsibility for tenant-supplied images.
• Monitor vendor updates: Because Microsoft’s statement is conditional ("If impact to additional products is identified, we will update the CVE"), maintain active monitoring of MSRC CVE pages, distro advisories, and the NVD/OSV entries so you receive any changes to product impact.

---

Strengths and limitations of Microsoft’s approach​

Strengths

• Transparency and process: Microsoft’s repeated messaging about publishing CSAF/VEX and updating CVE entries demonstrates a mature, process-driven approach to component disclosure and machine-readable advisory delivery. That’s a strong step for operational automation and customer awareness.
• Clear product scope: By naming Azure Linux explicitly, Microsoft helps customers prioritize patching where it matters most in their cloud ecosystem. Narrowing scope reduces unnecessary churn for systems that are not at risk.

Limitations and risks

• Potential for blind spots: Vendor statements are necessarily limited by the artifacts they scan. If a Microsoft product were to later ship an s390-enabled kernel, or if a marketplace image includes s390 support, the initial advisory might not have captured it. The vendor’s conditionality mitigates but does not eliminate this risk.
• Customer responsibility for marketplace images: Azure hosts a wide set of third-party images. Microsoft can state which Microsoft-delivered products are affected, but tenant-owned images or partner images require customers and ISVs to manage their own patching. That creates potential fragmentation in a shared cloud ecosystem.

---

Broader supply-chain and threat considerations​

CVE-2025-39694 is not a broad remote-execution wormable flaw — it is a local, architecture-specific logic error in kernel code. That reduces the immediate threat for general-purpose x86 and ARM fleets. Still, it highlights recurring themes in modern supply-chain risk:

• Component provenance matters. When kernel code for niche architectures is included in a build artifact, it creates a small but real attack surface that must be treated as part of supply-chain hygiene. Vendors that produce many kernel builds (for different architectures) must track and communicate impact across all products.
• Machine-readable advisories (CSAF/VEX) help scale response. Microsoft’s commitment to publish CSAF/VEX format advisories — and to keep product impact statements current — is helpful for enterprises automating triage and patch orchestration. But automation only works if the advisory metadata is complete and promptly updated.
• The cloud marketplace model complicates responsibility. Customers must treat marketplace and custom images as first-class artifacts for vulnerability management; cloud providers’ product statements cover their own products but cannot substitute for tenant inventory controls.

---

Final assessment and practical verdict​

• The vulnerability CVE-2025-39694 is a legitimate Linux kernel issue in the s390 SCLP driver and has been fixed upstream. Patch your s390x systems according to vendor advisories.
• Microsoft’s publicly stated position — that Azure Linux is the Microsoft product known to include the affected open-source component — is consistent with the technical facts and with Microsoft’s public advisories. That makes Azure Linux the Microsoft-branded product to prioritize for immediate action.
• Other Microsoft offerings such as WSL2 and standard Windows/Windows Server releases do not ship s390 drivers and are therefore not directly affected by this s390-specific CVE; operators should nonetheless validate custom kernels and third-party images in their environments. (github.com)
• Because vendor product-impact statements can evolve, operators must continue to monitor MSRC, distro advisories, and NVD/OSV entries. If Microsoft updates the CVE impact to include more products, you must treat those updates as authoritative and act accordingly.

---

Quick checklist for administrators​

• Identify any systems running s390x kernels (IBM Z): inventory and tag them as in-scope.
• If you use Azure Linux, apply the Azure kernel updates once published; consume CSAF/VEX data if available for automation.
• For WSL/custom kernels, confirm s390 drivers are not enabled in your builds. If they are, reconfigure and rebuild without s390 support or apply the upstream patch. (github.com)
• Verify marketplace and third-party images for s390x support and patch accordingly.
• Monitor vendor advisories for any expansion of product impact.

---

CVE-2025-39694 is an instructive case: a precise, architecture-specific kernel bug that underlines why vendors must pair technical accuracy with transparent communication. Microsoft’s current product impact statement correctly narrows the public scope to Azure Linux while leaving the door open for further updates — a pragmatic stance that puts the onus on customers to maintain accurate inventories and to follow vendor advisories for their particular deployments.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center