Microsoft has acknowledged that its Azure Linux distribution carries a Linux kernel vulnerability, tracked as CVE-2024-57875, that could cause denial-of-service conditions by triggering invalid memory references during disk operations. But the admission raises a thorny question for administrators: which other Microsoft-supplied Linux kernels and virtual machine images might also be affected? Currently, Azure Linux is the only product formally attested to contain the bug, but that doesn't mean your WSL2 instances or Azure Marketplace VMs are in the clear. This guide breaks down what the flaw is, what Microsoft has (and hasn't) confirmed, and exactly how to check your systems—then patch them.

What is CVE-2024-57875?

The vulnerability lives deep in the Linux kernel's block layer, the part that manages block devices like hard drives and SSDs. Specifically, it involves a race condition in how the kernel handles a bitmap pointer for zoned storage devices, known as conv_zones_bitmap. In unfixed kernels, when a disk is revalidated—perhaps after a hot-swap or a configuration change—the memory pointer that stores the conventional zone bitmap can be changed without proper synchronization. If another part of the kernel simultaneously reads that pointer, it can dereference invalid memory, leading to a kernel crash or, in worst-case scenarios, data corruption.

The upstream fix applies to kernel versions where the problematic code exists. The patch introduces a helper function, disk_set_conv_zones_bitmap, that uses RCU (read-copy-update) synchronization to safely replace the pointer, and wraps all reads with RCU-lock semantics. It's a small, surgical change, but a critical one for any system that uses zoned storage or has the kernel configuration option CONFIG_ZONE enabled.

Microsoft's Advisory: What It Actually Says

On its Security Update Guide, Microsoft states: “Azure Linux includes this open-source library and is therefore potentially affected.” The company has also released machine-readable CSAF (Common Security Advisory Framework) and VEX (Vulnerability Exploitability eXchange) attestations for Azure Linux, flagging it as impacted.

That language is precise: it confirms that Azure Linux images—the lightweight, cloud-optimized Linux distribution Microsoft maintains for Azure and edge devices—ship with the vulnerable kernel code. It does not, however, declare that other Microsoft products are free of the same code. Microsoft has committed to updating the CVE entry if additional products are found to be affected.

For security teams, this creates a clear action item for Azure Linux VMs. But it also leaves a gap. Consider these other Microsoft artifacts that ship Linux kernels:

  • WSL2 kernels: The Windows Subsystem for Linux 2 uses a custom Linux kernel delivered through Windows Update. If that kernel includes the affected block layer code, every Windows machine with WSL2 enabled could be exposed.
  • Linux-Azure kernels: Some Azure VM SKUs use specialized “linux-azure” kernels, which may share the same upstream code.
  • Azure Marketplace images: Official Microsoft images for Ubuntu, Debian, and other distros might not be covered by the Azure Linux attestation, and their patch status depends on the upstream distribution.
  • Container base images: Azure Kubernetes Service (AKS) node images and other managed container host images often include Microsoft-maintained kernels.
  • Statically compiled binaries: While less likely for a pure kernel CVE, some appliances or embedded systems might carry compiled-in kernel code.

Because these artifacts are built independently, their kernel versions and configurations vary. A blanket statement for Azure Linux doesn't automatically extend to them. As Microsoft's own advisory implies, the absence of an attestation doesn't mean absence of the flaw.

How We Got Here: Microsoft's Phased Transparency Push

This isn't the first time Microsoft has issued a single-product advisory for a widespread open-source component. The company is in the middle of rolling out a structured vulnerability disclosure program built around CSAF and VEX, designed to give customers machine-readable impact statements. Azure Linux was an early adopter because its images are centrally built and well-inventoried. Expanding that inventory to all product families takes time.

The approach has benefits: when an attestation exists, it provides an authoritative, automation-friendly signal that reduces false positives. But in this interim period, with attestations still partial, the burden shifts to customers to verify the status of other products.

Your Action Plan: Finding and Fixing CVE-2024-57875

1. Patch Azure Linux Immediately

If you run Azure Linux VMs, treat Microsoft's advisory as a definitive call to action. Update your kernel packages now. The fix is available through standard package repositories. For Azure Linux 2.0, for example, run:

sudo tdnf update kernel

After updating, reboot your VMs to load the new kernel. If you use Azure Update Manager or other automated patching, verify that the updates have been applied.

2. Inventory All Microsoft-Supplied Linux Images

Make a list of every place in your environment where a Microsoft-provided Linux kernel might be running:

  • Azure Linux VMs
  • WSL2 instances on Windows 10/11 machines
  • Azure Marketplace VMs (look for “linux-azure” kernels)
  • AKS node images and Azure Container Instances
  • Any cloud-based VMs or edge devices that use Microsoft’s Azure Linux

Do not assume that any of these are safe unless you see a specific vendor advisory stating “not affected.”

3. Check Your Kernel Versions and Configurations

For each system, determine the running kernel version. On Linux, use uname -r. Compare it to the list of affected versions provided by your distribution. Because the CVE impacts a specific kernel feature, you also need to check if the relevant configuration option is enabled.

On any Linux host, run:

zgrep CONFIG_ZONE /proc/config.gz

Or, if that file doesn't exist:

grep CONFIG_ZONE /boot/config-$(uname -r)

If you see CONFIG_ZONE=y or =m, the vulnerable module may be present. For a quick check on the symbol itself, search the kernel binary:

strings /boot/vmlinuz-$(uname -r) | grep conv_zones_bitmap

Any output suggests the buggy code is compiled in. On WSL2, you can run these commands inside your WSL distribution, but note that the WSL kernel is shared across all distros, so patching it requires updating the WSL kernel package from Windows.

4. Verify with Package Changelogs

Many distributions list fixed CVEs in package changelogs. For Debian/Ubuntu-based systems:

apt changelog linux-image-$(uname -r) | grep -i 57875

For RPM-based systems:

rpm -q --changelog kernel | grep -i 57875

If the CVE is mentioned and listed as fixed in a version you are running, you're safe. If not, you need an update.

5. Check Offline Images and Containers

For VM images or container images not yet running, inspect them statically. Unpack the image (using tar for VM images, or docker save/skopeo for containers) and then run the same strings and grep searches against the kernel binaries inside /boot and /lib/modules. Automation tools like Trivy or Grype can scan container images for CVEs, but they rely on distribution databases. Supplement with manual binary checks if the image uses a custom kernel.

6. For Windows/WSL2 Users: Update the WSL Kernel

If you rely on WSL2 for development or testing, check your WSL kernel version. Open PowerShell and run:

wsl --status

Look for the kernel version. Microsoft typically ships WSL kernel updates through Windows Update or the WSL GitHub releases page. If your kernel version is among those known to be vulnerable (check the release notes or the upstream Linux stable changelog), update manually by downloading the latest WSL kernel installer from Microsoft or by enabling automatic updates. After updating, shut down all WSL instances (wsl --shutdown) and restart.

7. Automate Future Attestation Ingestion

To stay ahead of Microsoft's expanding attestations, integrate their CSAF and VEX feeds into your vulnerability management tools. These machine-readable documents will automatically flag newly attested products, so you won't have to manually reprocess the CVE every time an advisory changes. Popular platforms like Dependency-Track, OWASP CycloneDX tooling, or commercial scanners can consume VEX.

What’s the Real Risk?

For most organizations, the practical risk is system instability rather than a remote attack. The vulnerability requires the ability to trigger disk revalidation, which typically needs local access or a specific set of conditions (like hotplugging a zoned storage device). On cloud VMs, an attacker with code execution could potentially crash the kernel by repeatedly triggering the race, causing a denial of service.

However, on systems that use zoned storage—increasingly common in cloud environments for database workloads—the risk is higher. The bug could also affect systems that don't explicitly use zoned drives if the kernel configuration includes the feature.

Outlook: More Attestations Are Coming

Microsoft's security team has signaled that this is a phased rollout, and we can expect more product families to receive CSAF/VEX coverage over time. That's good news for defenders who crave certainty. In the meantime, the only way to be sure is to verify your own artifacts. The good news is that patching is straightforward once you identify affected systems.

CVE-2024-57875 is a medium-severity flaw, but its fix is simple. By acting now on Azure Linux and verifying the rest of your Microsoft Linux footprint, you can close this exposure before it causes a production outage.