Microsoft has published its first official security advisory for a newly disclosed Linux kernel vulnerability, confirming that its Azure Linux distribution is potentially affected. The flaw, tracked as CVE-2025-38359, lives deep in architecture-specific code for IBM Z (s390) systems and can trigger kernel instability under certain conditions. While the advisory focuses narrowly on Azure Linux, it marks a new era of transparency for Microsoft’s open-source security responses—and a reminder that other Microsoft-built Linux artifacts remain unverified until further notice.

What changed

The vulnerability is a Linux kernel defect in the s390 memory-management code. Specifically, the do_secure_storage_access function in arch/s390/mm/fault.c can attempt to resolve a page fault in an atomic context, which the kernel forbids. Under the right debug or runtime conditions, this leads to kernel warnings or oops traces. The upstream fix is a targeted patch that corrects the in-atomic check.

On the Microsoft side, the MSRC (Microsoft Security Response Center) published a CSAF/VEX attestation stating that Azure Linux “includes this open-source library and is therefore potentially affected.” This notice is the first public acknowledgment from Microsoft for CVE-2025-38359. No other Microsoft product has been publicly attested for this CVE yet.

Microsoft began rolling out CSAF/VEX attestations in October 2025, promising to inventory more products over time. The Azure Linux advisory is an early output of that initiative—a machine-readable, product-scoped signal designed to help customers automate triage.

Who’s actually affected

The CVE is intrinsically tied to the s390x architecture. Only Linux kernels built for IBM Z mainframes or LinuxONE systems include the vulnerable code path. Kernels compiled for x86_64, ARM64, or other architectures do not contain the flawed function and cannot trigger the bug.

Azure Linux

The MSRC advisory makes Azure Linux the primary product of concern. Microsoft has explicitly inventoried its Azure Linux distribution and confirmed it contains the upstream component. If you run Azure Linux images—especially on s390x hardware—this CVE is actionable.

Windows Subsystem for Linux (WSL2)

Microsoft’s WSL2 kernel is built solely for x86_64 and arm64 architectures. The public WSL2 kernel repository documents a build flow that targets only those platforms. There is no supported s390x build for WSL. As a result, the WSL kernel does not carry the vulnerable code path in any practical sense. However, generic vulnerability scanners may still flag the WSL kernel package because it is “a Linux kernel” without architectural awareness. Administrators should confirm their WSL kernel architecture with uname -a and apply Microsoft’s latest WSL updates as routine maintenance, but the risk is negligible.

Other Microsoft artifacts

Marketplace VM images, AKS node images, container images, and Microsoft-published agents or SDKs may embed their own Linux kernels. Most of these are built for the same x86_64 and ARM64 architectures used by Azure’s mainstream services, but a minority could target s390x for hybrid or specialized deployments. Without a public attestation, customers cannot assume safety. Until Microsoft updates the CVE record or you verify the artifact’s build configuration, treat non-attested Microsoft-supplied kernels as unverified.

How we got here

The upstream Linux kernel community disclosed CVE-2025-38359 in the normal course of vulnerability management. The fix landed in the kernel source tree, and distribution vendors began backporting patches into their own kernels shortly after.

Microsoft’s shift toward CSAF/VEX attestations began in October 2025, when the company announced it would start publishing machine-readable security advisories for its expanding Linux portfolio. Azure Linux—the company’s in-house, hardened distribution used extensively across Azure services—was an early candidate for inventory. The attestation for CVE-2025-38359 is a direct result of that work.

The phased nature of the rollout means that while Azure Linux has now been checked, other Microsoft products that ship Linux kernels are still in the inventory pipeline. Microsoft has stated it will update the CVE record if additional products are found to be carriers.

What to do right now

Action depends on your role and environment. Here are prioritized steps:

1. Azure Linux administrators

  • Apply Microsoft’s kernel updates for Azure Linux as soon as they are available. Check the Azure Linux release notes and the MSRC advisory for patch details.
  • If you run Azure Linux on s390x, this is a high-priority fix. Reboot into the patched kernel.

2. WSL users and Windows administrators

  • Run uname -a inside your WSL distribution. If the displayed architecture is x86_64 or aarch64, the s390-specific flaw does not apply.
  • Update to the latest WSL kernel via wsl --update as part of your normal patching cycle, but do not treat this CVE as a critical WSL threat.

3. Administrators of other Microsoft-supplied Linux environments

  • Inventory all Linux kernels sourced from Microsoft (Marketplace images, AKS nodes, container images, etc.).
  • For each kernel, verify the target architecture and version:
    uname -a dpkg -l | grep linux-image # Debian/Ubuntu rpm -q kernel # RHEL/Azure Linux
  • Check the kernel config (if available) for CONFIG_S390. The presence of this option indicates s390x support.
  • For container images, inspect the OS/architecture with docker inspect --format='{{.Architecture}} {{.Os}}' <image>.

4. Monitor Microsoft’s advisory feed

  • Subscribe to the MSRC update guide for CVE-2025-38359. Microsoft will update the record if additional products are later attested as affected.
  • Bookmark the Microsoft CSAF/VEX portal (if publicly available) to track the expanding inventory.

5. Refine vulnerability scanning workflows

  • Many scanners lack architectural context and will flag any kernel package as vulnerable to CVE-2025-38359. Suppress these findings only after you have verified the kernel’s build architecture. Base your risk decisions on architecture, not generic package names.

What’s next

Microsoft’s investment in CSAF/VEX attestations will gradually reduce the uncertainty for customers. As more product inventories are completed, we can expect advisories for other Microsoft Linux artifacts—including Marketplace appliances, container base images, and possibly older distributions still in support. In the meantime, IT teams must treat non-attested artifacts with caution and perform their own verification.

The architectural specificity of this bug also highlights a broader challenge: vulnerability management must become context-aware. The days of blindly trusting scanner output are over. Operators will need to correlate CVE details with runtime architectures, kernel configs, and vendor attestations to separate noise from genuine risk.