Microsoft has confirmed that Azure Linux images contain a Linux kernel vulnerability that silently drops critical I/O flags in software RAID setups, potentially throttling disk throughput by an order of magnitude or causing stalled I/O under common conditions. The company published a machine-readable attestation for CVE-2025-22125 on March 12, 2025, marking Azure Linux as "potentially affected" and kicking off a broader rollout of automated vulnerability disclosures. But that single attestation doesn't close the case: Microsoft ships at least five distinct Linux kernel artifacts, and for four of them—including the WSL2 kernel, linux-azure images, Marketplace appliances, and CBL-Mariner derivatives—the company's official word remains "unknown."

The Bug That Corrupts I/O Intent

At the heart of CVE-2025-22125 lies a logic error in the Linux kernel's multi-device (md) RAID layer. When md/raid1 and md/raid10 assemble lower-level bio structures for a physical I/O operation, the code silently drops three flags that carry precise operational semantics: REQ_IDLE, REQ_META, and REQ_NOWAIT.

  • REQ_IDLE governs writeback throttling under the block layer's bandwidth controller (blk-wbt). When it goes missing, a write I/O that should bypass throttling gets treated as background noise—or the opposite, where urgent metadata writes stall behind bulk data. In cloud instances with default blk-wbt settings, this can slash write throughput to a fraction of expected performance.
  • REQ_META signals that the I/O carries filesystem metadata. Losing it confuses I/O schedulers and erases any priority boost that metadata operations rely on, increasing latency for journal commits and directory updates.
  • REQ_NOWAIT tells the lower device to fail immediately rather than block if resources aren't available. Without it, I/O that should fail fast can hang, changing the error recovery behavior of applications and filesystems.

Upstream patches, backported into multiple stable kernel lines, preserve these flags when constructing the sub-bios. Independent vulnerability databases and distribution advisories from Ubuntu, Debian, Red Hat, and others corroborate the description. The exploitation model is entirely local—an attacker needs access to trigger RAID I/O patterns—but the impact is especially meaningful in multi-tenant hosts, hypervisors, CI/CD runners, and any environment where untrusted code can generate disk load. No remote code execution vector exists.

Microsoft's Attestation: What It Says and What It Leaves Out

In its CVE-2025-22125 advisory on the MSRC portal, Microsoft states: "Azure Linux includes this open-source library and is therefore potentially affected." That sentence is the first machine-readable, product-scoped attestation the company has issued under its new CSAF/VEX transparency program. It tells Azure Linux customers definitively that their images contain the vulnerable md/raid code and must be patched or replaced.

But the advisory explicitly limits its scope to the Azure Linux product family—the CBL-Mariner lineage that Microsoft curates for Azure deployments. It does not claim that other Microsoft-built or Microsoft-distributed Linux kernels are free of the same code. The phased CSAF rollout, described in a companion blog post, starts with Azure Linux precisely because it's the easiest artifact for Microsoft to inventory and attest: a centrally built, single-source distribution. As the company's own documentation makes clear, additional product families will receive their own attestations as inventory work completes.

Until those attestations appear, the status of every other Microsoft Linux artifact is indeterminate. Absence of a VEX statement is not evidence of safety. It means Microsoft hasn't finished checking.

Who Needs to Act Right Now

Azure Linux Admins
If you run Azure Linux VMs or container hosts, the MSRC attestation is your green light to move. Microsoft's CSAF file marks these images as "Known Affected." Patch immediately through your normal Azure Linux update channel—the fix resides in updated kernel packages that incorporate the upstream md/raid flag preservation patches. If patching is impossible for some hosts, restrict untrusted user access to block devices and monitor disk I/O latency for anomalies.

WSL2 Users and Developers
The Windows Subsystem for Linux 2 kernel is a separate Microsoft-maintained artifact with its own repository and release cadence. Microsoft has not yet published a CSAF/VEX attestation for the WSL2 kernel, so you cannot assume immunity. To check your local WSL2 instance:

  1. Open a WSL2 terminal and run uname -r to get the kernel version.
  2. Compare that version against the upstream commit history for CVE-2025-22125 fixes (tracked in the Linux kernel Git repositories and distributor advisories).
  3. Verify configuration: if /proc/config.gz exists, run zcat /proc/config.gz | grep -E 'CONFIG_MD|CONFIG_BLK_WBT'. Look for CONFIG_MD, CONFIG_MD_RAID1, and CONFIG_MD_RAID10. Even if compiled as modules, the vulnerable code may be present.
  4. If the kernel version predates the fix and md/raid is enabled, request an updated WSL2 kernel from Microsoft or switch to a patched build.

Azure VM Users on linux-azure Kernels
Canonical's linux-azure package, which powers many Azure VMs running Ubuntu, ships a kernel that may include the md/raid modules. Microsoft has not attested this artifact. Run the same version and configuration checks. Ubuntu's CVE tracker (CVE-2025-22125) lists fixed package versions—update via apt if your kernel falls in the vulnerable range.

Marketplace and Appliances
Images from third-party publishers or custom derivatives (including your own CBL-Mariner builds) require publisher-level inventory. Check the publisher's security advisory or, failing that, perform artifact-level verification yourself. The commands above work for any Linux host, not just Microsoft-provided ones.

How We Got Here: A Transparency Shift Years in the Making

CVE-2025-22125 itself has a straightforward lineage: a regression introduced during md/raid refactoring, discovered by kernel developers, fixed upstream, and backported to stable trees. Its presence in Azure Linux is a consequence of how CBL-Mariner tracks upstream Linux—it inherits both the features and the bugs.

What makes this event notable is Microsoft's procedural response. For years, the company relied on text-based CVE entries and security bulletins that told customers only that a product might be affected, leaving the burden of confirmation on the user. With CSAF and VEX, Microsoft is moving toward machine-readable, product-scoped declarations that vulnerability management tools can ingest directly. The first cohort of attestations—Azure Linux images—serves as a proof of concept for the pipelines. The company promises to update CVE/VEX mappings "if additional products are identified as carriers," a phrase that signals an ongoing inventory process rather than a one-time statement.

Independent trackers, including the National Vulnerability Database and OSV, already link the upstream commits. Distributors have published their own advisories. Microsoft's new disclosure layer sits on top of all this: a vendor-specific, automation-friendly signal that answers the question, "Did we ship this code in this specific product?"

The Complete Verification Checklist

For any Microsoft-adjacent Linux host whose attestation is missing, run these commands to definitively assess exposure.

  1. Identify kernel and distro
    uname -a cat /etc/os-release

  2. Check config for md/raid support
    grep -E 'CONFIG_MD|CONFIG_BLK_WBT' /boot/config-$(uname -r) 2>/dev/null || zcat /proc/config.gz 2>/dev/null | grep -E 'CONFIG_MD|CONFIG_BLK_WBT'
    Presence of CONFIG_MD=y (or m) means the md subsystem is available. If CONFIG_MD_RAID1 or CONFIG_MD_RAID10 are set, the vulnerable code paths can execute.

  3. Look for active RAID arrays
    lsmod | egrep 'md|dm_mod' cat /proc/mdstat mdadm --detail /dev/mdX # for any existing arrays
    Even if no arrays are configured, a module loaded into memory can be triggered by an attacker who can create RAID devices.

  4. Map kernel version to fixed range
    Use the distributor advisory for your distro. For example, on Ubuntu, visit https://ubuntu.com/security/CVE-2025-22125 and note the fixed package versions. Compare with dpkg -l linux-image-*. On Debian, use the security tracker. On Fedora/RHEL, check the Red Hat advisory.

  5. Automate the inventory
    - Ingest Microsoft's CSAF/VEX feeds (available from the MSRC provider metadata page) into your vulnerability management platform.
    - Use image scanning tools (Trivy, Clair, etc.) to correlate running kernel strings with fixed versions from your Linux vendor.
    - For code you can't boot (e.g., container images), extract the kernel package manifest and check against vendor advisories.

Immediate Workaround If You Can't Patch

  • Restrict device access: Ensure only trusted processes can open block device files. Use cgroups or seccomp profiles to deny ioctl and open on dev/sd* and /dev/md* to untrusted containers.
  • Throttle untrusted I/O: Apply blkio cgroup limits to workloads that might be attempting to trigger RAID activity.
  • Isolate unpatched hosts: Move them to a dedicated VLAN or network segment to limit lateral movement if an attacker already has a foothold.

What's Next

Microsoft's phased CSAF/VEX rollout will eventually cover more product families, likely including WSL2 and linux-azure kernels. Until then, treat every unpatched Microsoft Linux artifact as a candidate for CVE-2025-22125, verify through artifact inspection, and automate the ingestion of future attestations. The gap between Azure Linux's confirmation and the rest of the portfolio is a predictable side effect of a transparency initiative that's just getting started—and a reminder that in open-source supply chains, vendor attestations always need your own verification.