Azure Linux Attestation for CVE-2025-38359: s390 Architecture Risk

Microsoft’s brief attestation that Azure Linux “includes this open‑source library and is therefore potentially affected” is accurate as a product‑level statement — but it is not a categorical proof that no other Microsoft product could contain the same vulnerable code. Azure Linux is the only Microsoft product Microsoft has publicly mapped and published for this CVE so far, yet the technical nature of CVE‑2025‑38359 (an architecture‑specific kernel fix in the s390 code path) and Microsoft’s phased CSAF/VEX rollout mean customers must treat the attestation as authoritative for Azure Linux and remain cautious about other Microsoft artifacts until they are explicitly inventoried.

---

Background / overview​

CVE‑2025‑38359 is a Linux kernel fix described as: “s390/mm: Fix in_atomic handling in do_secure_storage_access”. The problem arises when kernel user‑space accesses to non‑exported pages happen in an atomic context on the s390 (IBM Z / LinuxONE) architecture; under certain debug or runtime conditions the kernel can try to resolve a page fault while it is not allowed to sleep, producing kernel warnings or oops traces. The canonical public entries — the NVD summary and upstream Linux CVE announcement — describe the affected file (arch/s390/mm/fault.c) and recommend upgrading to a kernel that contains the upstream patch. This CVE is architecture‑specific: the problematic code lives in the s390 architecture tree. That matters tremendously for scope and risk: only kernel builds that include the s390 architecture support — i.e., kernels built for IBM Z (s390x) or distributions that package s390 kernels — can carry this code path in a meaningful way. Distributions and vendors that ship kernels configured for x86_64 or ARM64 only will not run the s390-specific codepaths at runtime and therefore are not practically affected by this exact defect.

---

What Microsoft published and how to read it​

Microsoft’s MSRC entry (the statement you quoted) is a product‑scoped inventory attestation: it reports that Microsoft examined the Azure Linux distribution artifacts, found the relevant upstream component in that product’s build, and therefore marked Azure Linux as potentially affected. Microsoft has also stated it began publishing CSAF/VEX attestations in October 2025 and will expand those attestations as more product inventories complete. That means the MSRC text is a reliable, machine‑readable signal for Azure Linux customers — but it is not a blanket claim that other Microsoft SKUs are proven clean.
Two practical consequences flow from that phrasing:

• For customers running Azure Linux images, the MSRC attestation is an authoritative instruction to treat the product as in‑scope for triage and patching. Prioritize Azure Linux kernels and images in remediation workflows when Microsoft marks them as “potentially affected.”
• For other Microsoft artifacts (WSL kernels, linux‑azure builds used in certain marketplace images, Marketplace appliances, container images Microsoft publishes, or Microsoft‑built Go/Python binaries), absence of a VEX attestation is absence of evidence, not evidence of absence. Microsoft’s phased rollout means other products may be checked and attested later, and Microsoft has stated it will update CVE/VEX records when that mapping completes. Treat non‑attested Microsoft artifacts as unverified until you can confirm their inventory.

---

The technical truth about “who’s affected”​

• The upstream kernel maintainers and CVE notices place the fix squarely in the s390 architecture code (arch/s390/mm/fault.c). That means the defect only matters for kernels that were built for the s390 architecture or kernels that enabled s390‑specific code.
• Microsoft’s publicly attested product for this vulnerability is Azure Linux (the Azure‑branded Linux distribution / kernel artifacts Microsoft publishes). That is the product Microsoft has validated and disclosed as including the implicated open‑source code. In short: Microsoft has said Azure Linux includes the component and therefore is potentially affected.
• Other Microsoft products that ship Linux kernels — for example, Windows Subsystem for Linux 2 (WSL2) — are not obviously carriers of this s390 fix simply because they ship a Linux kernel. The WSL2 kernel provided by Microsoft is built and configured for the Windows host architectures (x86_64 and, in some builds, arm64) and the WSL2 repo explicitly documents building an x86_64 WSL2 kernel, not an s390 image. That architectural mismatch strongly argues WSL kernels are not vulnerable to an s390‑only kernel defect in practical terms.
• That said, if any Microsoft product (including internal images, Marketplace appliances, or vendor‑supplied binaries) contains an s390‑targeted kernel build or distributes an s390‑built artifact to IBM Z customers or partners, those artifacts would be in scope. Public evidence so far shows Microsoft attested Azure Linux first and has not (yet) attested other products for this CVE. Absence of attestations for other products is not a technical guarantee of absence.

---

Cross‑checking the public records (evidence)​

To validate the public facts, I cross‑checked multiple independent sources:

• The NVD entry and several vendor trackers mirror the upstream description of CVE‑2025‑38359 as a fix in the s390/mm fault handling logic. This confirms the CVE details and upstream file location.
• Linux distribution advisories (Ubuntu’s security notice and other distributor trackers) list the CVE and map fixes into their packaged kernels, consistently calling out the s390 architecture in the affected subsystems where applicable. This shows mainstream distros treat the issue as an architecture‑specific kernel correctness fix.
• Microsoft’s own product mapping program (CSAF/VEX attestations) has, as part of its phased rollout, published an attestation for Azure Linux families; public discussions and vulnerability‑tracking threads have analyzed Microsoft’s wording and emphasize that the attestation is product‑scoped. In other words: Microsoft confirmed Azure Linux contains the affected upstream code and will update attestations if more Microsoft products are found to include it.
• The WSL2 Linux kernel repository maintained by Microsoft documents building an x86_64 kernel and provides an explicit x86_64 build flow, which supports the practical conclusion that the WSL kernels are not shipping s390 targets. That repo is publicly accessible and shows Microsoft’s kernel artifact lineage for WSL2.

These independent traces (upstream kernel mailing lists and CVE announcements, distro advisories, and Microsoft’s publicly visible attestations and repos) together support the core conclusions above: (1) the CVE is s390‑specific; (2) Microsoft explicitly attested Azure Linux; and (3) there is no public attestation showing other Microsoft products contain a s390 kernel build for this CVE at the time of the disclosure.

---

What this means for administrators and operators (practical guidance)​

Short answer: if you run Azure Linux images, treat this CVE as actionable and apply Microsoft’s kernel updates. If you run other Microsoft artifacts (WSL, Marketplace images, AKS node images, Microsoft‑provided binaries), verify whether those artifacts include s390‑targeted kernels or the vulnerable component before assuming they’re unaffected.
Actionable checklist (prioritized):

• Prioritize Azure Linux images and kernels
• Apply Microsoft’s updates for Azure Linux as soon as they are available and validated in your environment. Microsoft’s attestation makes Azure Linux the primary remediation priority for customers using that product.
• Verify architecture and kernel configuration for all Microsoft‑supplied kernels
• On machines under your control, check uname -a and your kernel package metadata to confirm architecture and version.
• Inspect kernel packaging and build metadata for flags that enable s390 code (this is usually a compile‑time choice — s390 support is not enabled for x86 builds). See kernel config items like CONFIG_S390 for context.
• For WSL / Windows hosts
• WSL kernels are built for x86_64/arm64 and the Microsoft WSL2 repo documents x86_64 build instructions; verify your WSL kernel versions and apply Microsoft WSL updates as you would normally, but the s390‑specific CVE should not apply to x86‑only WSL kernels. Still, confirm via your WSL kernel release numbers and Microsoft advisories.
• Inventory other Microsoft artifacts you run
• Marketplace VM images, container images, and Microsoft‑published agents or SDKs can include their own kernel or carry native binaries that might have been built for other targets. Don’t assume a VEX attestation for Azure Linux covers these. Treat them as separate artifacts and scan image manifests, SBOMs, or package metadata.
• Watch MSRC/CSAF/VEX feeds
• Microsoft has committed to publishing and updating CSAF/VEX attestations for additional products — subscribe to Microsoft’s VEX/CSAF output or the MSRC update guide to catch any expansion of the product list. Microsoft will update the CVE record if other products are found to be carriers.
• If you manage IBM Z (s390x) infrastructure
• This CVE is directly relevant; follow upstream kernel and your distribution vendor’s guidance, install backported fixes, and reboot into patched kernels. Distributors typically publish package updates mapping the upstream commit that fixed the CVE.

---

Risk analysis and critical appraisal​

Strengths of Microsoft’s approach

• Microsoft’s shift to publishing CSAF/VEX attestations for product inventories is a meaningful step for transparency. Product‑scoped attestations let customers automate triage and prioritize remediation when a vendor confirms a product contains a vulnerable component. Microsoft explicitly said it began that rollout in October 2025 and will expand it — an operationally useful commitment for customers.
• For Azure Linux customers, a published attestation removes ambiguity: Microsoft has done the inventory work for that product, saving customers time and reducing triage friction.

Limitations and residual risks

• Phased attestations create a window of uncertainty for other Microsoft artifacts. If you run Microsoft‑branded images, kernels, or containers (beyond Azure Linux), you cannot assume safety until the vendor has completed inventory or you have independently verified the artifact. In short: absence of attestation ≠ proof of absence. This is the central caveat Microsoft’s wording implies but does not always make explicit in short advisories.
• The CVE being architecture‑specific reduces the surface area of risk but also complicates automation: many asset scanners will flag a CVE generically for any kernel package if they are not architecture‑aware, producing noisy alerts. Operators must correlate package metadata with build configuration and target architecture to determine real exposure. Upstream documentation and distro advisories help here.
• There is also a long‑tail vendor patching problem for embedded or vendor‑forked kernels. Microsoft’s attestation helps for Azure Linux images; other vendor forks or OEM kernels may lag in backporting fixes. If you rely on third‑party appliances or older vendor kernels, push vendors for explicit commit references or package changelogs that include the upstream patch.

Unverifiable or uncertain points (flagged)

• Internal Microsoft build inventories, private images, or partner artifacts are not fully public. It is therefore not verifiable from outside whether Microsoft has any other internal or partner artifacts that include an s390 build and thereby include the vulnerable code. Microsoft’s public attestation process is improving this, but until Microsoft attests or a vendor‑supplied SBOM enumerates the component, those claims remain outside public verification. Treat such cases with caution and seek vendor confirmation where you rely on Microsoft artifacts in sensitive deployments.

---

Example verification steps for operators (quick commands and checks)​

• Confirm kernel architecture and version:
• uname -a
• dpkg -l | grep linux-image (Debian/Ubuntu) or rpm -q kernel (RHEL/CBL‑Mariner/Azure Linux)
• Check kernel .config (if available) for CONFIG_S390 or related s390 config options.
• On WSL systems:
• wsl --status to check WSL version
• Confirm WSL kernel release: cat /proc/version or uname -a inside the WSL distro
• Compare against Microsoft WSL release notes and the WSL2‑Linux‑Kernel repo builds.
• For container images:
• Inspect image OS/arch: docker inspect --format='{{.Architecture}} {{.Os}}' <image>
• Scan image layers with a vulnerability scanner that understands package metadata and architecture (Trivy, Clair, Snyk).
• For Azure customers:
• Use Azure Update Management, Azure Security Center recommendations, or your image lifecycle tooling to apply Microsoft’s published Azure Linux kernel updates promptly.

---

Conclusion​

Microsoft has publicly attested that Azure Linux includes the open‑source library implicated by CVE‑2025‑38359 and is therefore potentially affected; that attestation is the authoritative product‑scope statement you should act upon if you run Azure Linux images. However, because the CVE is s390-architecture specific and Microsoft’s CSAF/VEX rollout is phased, you must not assume Azure Linux is the only Microsoft product that could carry the vulnerable code. In practice:

• If you run Azure Linux, treat this as high priority: install the vendor kernel updates and reboot.
• If you run other Microsoft artifacts (WSL kernels, Marketplace images, container images, or Microsoft binaries), perform artifact‑level inventory checks — verify architecture, kernel config, or SBOMs — and do not rely solely on the current absence of a Microsoft attestation as proof of safety.
• Monitor MSRC/CSAF/VEX outputs and vendor advisories for updates; Microsoft has said it will expand the attestations and update the CVE mapping if further products are identified as carriers.

This combination of product‑scoped transparency (beneficial) and phased rollout (causing interim uncertainty) is the core operational takeaway: act immediately where Microsoft has attested (Azure Linux), and treat every other Microsoft‑supplied artifact as unverified until you can prove otherwise.

---

---

Source: MSRC Security Update Guide - Microsoft Security Response Center