Microsoft has confirmed that Azure Linux is vulnerable to a just-patched Linux kernel flaw that can crash systems, but its advisory stops short of clearing other Microsoft products like WSL2 – leaving administrators to verify their own exposure. The vulnerability, tracked as CVE-2025-37826, resides in the Universal Flash Storage (UFS) SCSI driver and could allow a local attacker to cause a denial-of-service by triggering a NULL pointer dereference. While the fix is already upstream and rolling out via distribution updates, the partial nature of Microsoft’s attestation means many Microsoft-supplied Linux environments remain a question mark until individually checked.

The Bug: A Missing NULL Check in the UFS Driver

At the code level, the problem is deceptively simple. The Linux kernel’s UFS SCSI stack, specifically the ufshcd_mcq_compl_pending_transfer function, can call ufshcd_mcq_req_to_hwq, which sometimes returns a NULL hardware-queue pointer. Without an explicit guard, that NULL pointer is dereferenced, crashing the kernel. Linux kernel maintainers merged the fix – a straightforward NULL check – into stable trees, and distributions have been backporting it into their kernel packages. The National Vulnerability Database and various Linux security trackers now list the CVE alongside fixed package versions.

Microsoft’s response came via its Security Response Center (MSRC) advisory, which states: “Azure Linux includes this open-source library and is therefore potentially affected.” The company said it will publish machine-readable CSAF/VEX attestations for Azure Linux and update the CVE mapping if additional products are found to carry the vulnerable code.

What the Advisory Does – and Doesn’t – Cover

For Azure Linux users, the advisory provides a clear, vendor-validated signal: patch now. But the language is carefully scoped. It is a product-level inventory assertion for Azure Linux only. Microsoft has not publicly attested that the same vulnerable component is absent from other artifacts like Windows Subsystem for Linux 2 (WSL2) kernels, Azure Marketplace images, or custom kernel builds used in managed services. The advisory’s wording – “if additional Microsoft products are identified as carriers” – confirms that further scanning is still underway.

This matters because the UFS driver’s inclusion in any given kernel build depends on compile-time configuration (CONFIG_SCSI_UFS and related options), whether it’s built-in or a module, and the kernel version. A WSL2 kernel image, for example, might use a configuration that includes the driver even if the host hardware has no physical UFS controller. Similarly, Marketplace virtual machine images and appliance kernels often carry a broad set of drivers for compatibility. Without a per-artifact attestation, administrators must assume those could be vulnerable until proven otherwise.

How We Got Here

The vulnerability came to light through routine upstream kernel maintenance. The missing NULL check had existed in the UFS driver code for an indeterminate period before researchers or maintainers identified it. Once the fix was developed, it entered the stable kernel channels in early 2025. Distribution security teams then picked it up: Debian, Ubuntu, Amazon Linux, and others published their own advisories, marking affected package versions or declaring certain releases not-affected because the code path isn’t present.

Microsoft’s involvement is part of a broader push toward automated vulnerability reporting. The company has been rolling out CSAF/VEX (Common Security Advisory Framework / Vulnerability Exploitability eXchange) documents to give customers machine-readable vulnerability data. The Azure Linux attestation for CVE-2025-37826 is an early example of that initiative, and Microsoft has publicly stated it will expand coverage as internal inventory work progresses.

What This Means for You

The practical impact depends on which Microsoft-supplied Linux artifacts you operate:

  • Azure Linux users: Your official images are confirmed vulnerable. Prioritize patching immediately using Microsoft’s published CSAF/VEX data and standard image update mechanisms. The advisory is authoritative for this product family.
  • WSL2 users: The WSL2 kernel is a separate artifact built by Microsoft, but the company has not yet issued a VEX statement for it. By default, WSL2 uses a Microsoft-provided kernel that might include the UFS driver. If you use the default kernel, check your version and configuration. If you run a custom WSL kernel, verify it independently.
  • Administrators managing Marketplace images, AKS node images, or other Microsoft-published Linux appliances: No blanket attestation exists. Treat each image as an individual artifact. Verify kernel configurations, module presence, and patch levels manually or through your vulnerability management tools.
  • Home users running WSL for development or learning: The risk is lower, but a crash could disrupt work. If you’re using the default WSL2 kernel, updating Windows (which may ship a newer kernel) or manually upgrading the WSL kernel can close the gap. The steps below apply to you as well.

What to Do Now: A Step-by-Step Guide

Because the advisory doesn’t cover all Microsoft products, you need to inventory and verify. Here’s how to check each type of system, followed by remediation steps.

Step 1: Inventory All Microsoft-Supplied Linux Instances

List every host, virtual machine, container, or WSL instance that runs a kernel from Microsoft. Include Azure VMs running Azure Linux, Marketplace images, WSL2 distributions, and AKS (Azure Kubernetes Service) node images.

Step 2: Verify Exposure on Each System

On any running Linux host, run these commands:

  • Check kernel version: uname -r – compare against the fixed version provided by your distribution’s advisory.
  • Check if the UFS module is loadable: modinfo ufs and modinfo ufshcd (may require sudo). If these return information, the module is available.
  • Check if the UFS module is currently loaded: lsmod | grep ufs. An empty result doesn’t guarantee safety if the module is built-in.
  • Inspect kernel compile options: zgrep CONFIG_SCSI_UFS /proc/config.gz or check /boot/config-$(uname -r). Look for CONFIG_SCSI_UFS=m or =y. If present, the driver is compiled.
  • Search changelogs for the CVE: On Debian/Ubuntu: apt changelog linux-image-$(uname -r) | grep -i 37826. On RPM-based systems: rpm -q --changelog kernel | grep -i 37826.

For offline images (RPM packages, .deb files, container images), use similar methods: inspect the package file list or config files inside the image.

What to look for: The presence of drivers/ufs/core/ufshcd.c in the kernel source isn’t enough; you need to confirm whether it was compiled into your running kernel and whether the kernel version predates the fix commits. Cross-reference your kernel version with your distribution’s security tracker to see if it contains the patch.

Step 3: Patch Affected Systems

If you confirm a vulnerable kernel:

  1. Obtain the fixed package. For Azure Linux, use Microsoft’s official image updates. For other distributions, use apt upgrade or yum update to get the vendor-supplied kernel update.
  2. Schedule a maintenance window and reboot. Kernel updates require a restart. Test in a staging environment first.
  3. Validate after reboot: Run uname -r to confirm the new kernel, check that the module status or config files reflect the update, and search kernel logs for prior oops/panic signatures. Verify the CVE ID appears in the new kernel’s changelog.

Step 4: Mitigate If Patching Isn’t Immediate

If you can’t patch right away, reduce the attack surface:

  • Restrict access to device nodes that could exercise the UFS driver. In particular, limit /dev/ access for untrusted containers or local users.
  • Use SELinux, AppArmor, or other LSMs to confine processes that interact with SCSI subsystems.
  • Isolate image-processing pipelines and CI/CD runners that might trigger the code path inadvertently.

Step 5: Automate for Azure Linux

For Azure Linux images, ingest Microsoft’s CSAF/VEX JSON feeds into your vulnerability management system. This will automate detection and prioritization for those specific images, saving manual effort.

The Bigger Picture: Microsoft’s Shifting Vulnerability Disclosure

This advisory is a milestone in how Microsoft handles vulnerabilities in open-source components it ships. The public commitment to machine-readable VEX documents is a positive step toward transparency. It allows enterprises to move from manual CVE hunting to automated, artifact-level decisions. However, the current scope is narrow: only Azure Linux receives that automated signal today. The gap for WSL2 and Marketplace images is a reminder that VEX coverage is a journey, not a finished product. Administrators who assume that Microsoft’s silence on those products equals “not affected” risk leaving exploitable systems unpatched.

The Linux kernel’s modularity cuts both ways. A driver can be omitted from a kernel build, but the default configurations Microsoft ships for general-purpose images often include broad hardware support. Until Microsoft explicitly lists those images in its VEX feed, prudence demands independent verification.

Outlook

Microsoft has pledged to update the CVE mapping as product inventory work completes. Expect new VEX attestations for additional products in the coming weeks. In the meantime, treat any Microsoft-shipped Linux kernel as potentially affected if it’s not explicitly covered by the advisory. For Windows users who interact with Linux only through WSL, the burden is modest: check your WSL kernel version and update if needed. For cloud operators, the task is larger but manageable with the steps above.

The broader lesson is clear: when a vendor says “Product X is affected,” that doesn’t mean Products Y and Z are safe – it means they haven’t been checked yet. Verify, don’t assume.