CVE-2025-38063: Linux Device Mapper IO Throttle Fix in Azure Linux

A targeted fix landed in the Linux device-mapper subsystem to stop an unexpected IO throttle that could occur when a flush request carried the REQ_PREFLUSH flag; Microsoft’s public advisory lists Azure Linux as the Microsoft-distributed product that “includes this open‑source library and is therefore potentially affected,” but that product-level attestation is a scoped inventory statement — it confirms Azure Linux as a known carrier, not that it is the sole possible Microsoft carrier of the vulnerable kernel code.

Background​

The problem tracked as CVE-2025-38063 is a Linux kernel-level bug in the device-mapper (dm) layer that can cause an unconditional I/O throttle when a flush bio with REQ_PREFLUSH is processed. The bug was publicly recorded in the mid‑2025 disclosure cycle (published 18 June 2025 with subsequent updates in later months), and maintainers applied a small, focused fix in the dm code paths to avoid creating flush bios that get throttled by the writeback throttle (wbt) subsystem.
This is an availability-focused kernel issue: the vulnerable behavior can cause kernel worker threads handling flushes to block on wbt_wait, causing I/O progress to stall and potentially producing scheduling stalls, hung workqueues, or higher-level application I/O delays. Distribution security trackers and upstream kernel trees include the same technical description and list the stable backports and package updates that incorporate the fix.

What Microsoft actually said (and what that wording means)​

Microsoft’s public CVE guidance names Azure Linux as the Microsoft product that “includes this open‑source library and is therefore potentially affected,” and notes that Microsoft began publishing machine‑readable CSAF/VEX attestations in October 2025 and will update the CVE entry if additional product impact is discovered.

• That statement is a product‑scope attestation. It represents the outcome of Microsoft’s inventory and mapping work for the Azure Linux family at the time Microsoft published the guidance.
• It is not a blanket statement about every Microsoft artifact. Absence of attestations for other Microsoft products is not confirmation that those products are free of the vulnerable code — it may simply mean Microsoft has not yet completed inventory, mapping, or VEX production for them.
• Operational implication: Azure Linux customers have an authoritative, actionable signal that their Azure Linux images and kernels are in‑scope and should be remediated per Microsoft guidance. Customers running other Microsoft-provided Linux artifacts must perform per‑artifact checks to confirm whether their specific kernels include the upstream device-mapper code in the vulnerable commit range.

Why Azure Linux is the one Microsoft product named (inventory phasing)​

Large vendors commonly roll out VEX/CSAF attestations in phases. Microsoft chose Azure Linux — the Microsoft‑published Linux distribution (CBL‑Mariner lineage rebranded to Azure Linux) — as an initial mapping target because it is a well-defined product family with a single package/repo and a clear kernel build pipeline. That makes automated inventory and attestations straightforward to publish.
Other Microsoft‑distributed Linux artifacts exist and are plausible carriers of upstream kernel code, including:

• The WSL2 kernel Microsoft maintains and publishes (the WSL2 kernel repository and its prebuilt kernels).
• Azure kernel artifacts used in some Marketplace images, custom VM images, or “linux‑azure” kernel packages.
• Marketplace appliances and third‑party images published to Azure that include kernels Microsoft may have built or modified.
• Container host images and node images used by managed services (for example, images used for virtual machine scale sets or AKS node images) that can include a Linux kernel build carrying upstream dm code.

Any of these artifacts could carry the vulnerable dm code if they were built from kernels in the upstream commit ranges predating the fix and compiled with device‑mapper support enabled.

---

Technical anatomy of the vulnerability​

What happens inside the kernel​

When a bio that contains the REQ_PREFLUSH flag is submitted through the device-mapper layer, the dm path that synthesizes an “empty” flush bio for the lower device historically generated a flush_bio with flags REQ_OP_WRITE | REQ_PREFLUSH | REQ_SYNC. Because of that combination, the flush_bio could be subject to the kernel’s writeback throttling code (wbt), including wbt_wait. The writeback throttle is intended to prevent overwhelming storage devices under pressure, but some flush paths — especially those carrying filesystem metadata flushes (for example, XFS log flushes) — must not be throttled, otherwise metadata commits can be blocked indirectly.
The fix changes the flush_bio flags conditionally (for example, adding REQ_IDLE) so the wbt_should_throttle check returns false and the flush path is not throttled, removing the unintended blocking behavior.

Scope and impact​

• Primary impact: Availability — IO stalls, hung worker threads, and delays in filesystem metadata flushes. The canonical examples in vendor advisories show XFS metadata write threads blocked behind throttled flush bios.
• Exploitability: Not a remote code execution or privilege escalation vector by itself. The bug is triggered by I/O paths and typically requires local activity that submits flush bios with REQ_PREFLUSH. The implication for operators is that attacker-controlled workloads that can generate the relevant IO patterns could cause denial‑of‑service or resource starvation affecting other workloads on the same host.
• Affected component: Core Linux kernel device-mapper module (dm). Any distribution or kernel artifact containing the vulnerable dm code and compiled with device-mapper (CONFIG_BLK_DEV_DM) could reproduce the behavior.

Cross-checks and verification (what independent trackers show)​

Multiple distribution security trackers, the upstream kernel commit history, and third‑party vulnerability databases independently describe the same bug, the same root cause, the same fix, and the same general risk profile (availability). Distribution advisories show which package releases and stable kernels include the fix, and the upstream commit is present in the kernel trees and stable backports. The CVE publication timeline and distribution advisories provide the mapping from upstream commit to distribution kernel packages that operators use to decide which specific kernel packages to update to.

---

Is Azure Linux the only Microsoft product that includes the library and could therefore be affected?​

Short answer: No — Azure Linux is the only Microsoft product Microsoft has publicly attested as including the vulnerable open‑source kernel code for CVE‑2025‑38063 at the time of the advisory, but it is not technically or operationally guaranteed to be the only Microsoft artifact that could contain the code.
Why that distinction matters:

• Microsoft’s public attestation for Azure Linux is authoritative for that product family — treat Azure Linux images and kernels as in‑scope and apply Microsoft’s kernel updates promptly.
• A conservative vendor attestation helps reduce noise: it gives a clear, automatable signal to customers running the Azure Linux artifacts Microsoft inspected.
• However, any Microsoft distribution or artifact that ships a Linux kernel binary built from upstream commits in the vulnerable range and with device‑mapper compiled in is a plausible carrier until verified. That includes WSL2 kernels and other Microsoft-supplied kernel images or images published in the Azure Marketplace.

Put plainly: Microsoft has said Azure Linux is included; Microsoft has not yet declared additional products, but the absence of those attestations does not prove absence of the vulnerable code elsewhere.

---

Practical, actionable steps for administrators and engineers​

Operators must assume a phased reality: if you run Azure Linux images, apply Microsoft’s updates now; if you run other Microsoft-provided Linux artifacts (WSL2 kernels, Marketplace images, AKS node images, custom images downloaded from Microsoft repos), verify them.

1) Determine whether a given host or image carries the vulnerable dm code​

Run these checks on each target host or image to determine presence of device-mapper support and kernel version:

• Check kernel release:
• uname -r
• uname -a
• Check whether device-mapper is enabled in the running kernel:
• If the system exposes kernel config:
• zgrep CONFIG_BLK_DEV_DM /proc/config.gz
• grep CONFIG_BLK_DEV_DM /boot/config-$(uname -r)
• If the kernel config is not available, inspect modules:
• lsmod | grep dm_mod
• lsmod | grep dm_
• modinfo dm_mod
• For specific targets:
• modinfo dm-crypt
• modinfo dm-multipath
• Check for loaded device-mapper targets that are commonly used:
• lsblk
• dmsetup ls
• Compare kernel version and vendor package version against distribution advisories and stable backports to determine whether the kernel includes the upstream fix (you will need mapping from upstream commits to your distro’s kernel package).
• For WSL2:
• From within the distro: uname -r and cat /proc/version
• From Windows: wsl --status to see whether WSL is using the default Microsoft kernel; use wsl --update to fetch the Microsoft‑maintained kernel updates.

2) Apply patches and updates​

• Azure Linux (CBL‑Mariner / Azure Linux images):
• Use the distribution package manager (tdnf) to update kernel packages:
• sudo tdnf update
• sudo tdnf -y upgrade kernel* or sudo tdnf -y update
• Reboot hosts after installing a new kernel package.
• Ubuntu, Debian, Red Hat, SUSE, Amazon Linux, and other distros:
• Follow the vendor advisories for the fixed kernel package name and version. Install the distribution kernel update and reboot as required.
• WSL2 users:
• Run wsl --update to get the latest Microsoft-provided kernel image.
• If you run a custom WSL kernel, rebuild or obtain a kernel with the backported fix.
• Container images and Marketplace appliances:
• Replace node images and container host images with updated base images that include the patched kernel. For VMs, provision with updated images or apply kernel updates inside the guest and reboot.
• Update orchestration:
• For cloud fleet workloads, use automation (image baking, VMSS image upgrades, rolling kernel reboots) to minimize downtime while deploying updated kernels.

3) Short-term mitigations (if immediate patching is not possible)​

• Isolate workloads that can generate heavy flush patterns and ensure they do not run on the same hosts as critical workloads.
• Limit local user access on multi‑tenant hosts to reduce the attack surface for local workloads that could intentionally generate harmful I/O patterns.
• Monitor I/O latency, worker thread stalls, and dmesg for repeated scheduling warnings or block layer throttling messages that might indicate the condition is occurring.
• For storage-backed VMs, consider moving critical metadata-heavy workloads to patched hosts first.

4) Detection and monitoring guidance​

• Instrument kernel logs and telemetry for signs of throttled flush bios and scheduling stalls:
• Monitor dmesg and syslog for wbt_wait, rq_qos_wait, and related stack traces indicating blocked I/O.
• Track node-level metrics:
• I/O latency spikes, increased IO wait, unusual worker thread counts, or thread states indicating stalling.
• In cloud environments, monitor platform telemetry for kernel-level warnings or VM reboots correlated with heavy flush activity.

---

Recommended verification checklist for Microsoft customers​

• Identify all Microsoft‑provided Linux artifacts in your environment: Azure Linux images, images pulled from Microsoft repositories, WSL2 kernels, Azure Marketplace appliances, AKS node images, VM images that were patched or built by Microsoft.
• For each artifact, confirm kernel version and whether device‑mapper is compiled in (CONFIG_BLK_DEV_DM).
• Cross‑reference the kernel versions against distribution advisories and upstream commit mapping to confirm whether the fix is present.
• Apply vendor-supplied kernel updates and reboot as appropriate.
• If you rely on third‑party Marketplace images, enforce an image provenance policy and require vendors to publish if and when they have applied the fix.

---

Risk assessment and operational impact​

• For single-tenant VMs and developer desktops: The risk is likely moderate; the bug requires I/O patterns that produce REQ_PREFLUSH and only affects systems where device-mapper is present and the kernel is within the vulnerable commit range. Application-level impact typically shows as I/O latency or temporary unresponsiveness rather than data corruption.
• For multi‑tenant or shared hosts: The threat is more operationally significant. An unprivileged or low‑privileged tenant process that can generate the relevant flush I/O patterns could potentially affect co‑tenants by causing kernel worker threads to block, creating resource contention and availability degradation.
• For cloud providers and platform teams: Patch quickly and use rolling updates to minimize downtime. Publish clear attestations for customers — Microsoft’s approach to begin with Azure Linux and publish CSAF/VEX is operationally sound, but customers must not assume that other Microsoft artifacts are safe until Microsoft either attests them or the customer verifies them.

---

Why customers should not treat the MSRC attestation as a blanket guarantee​

Vendors publish product-level attestations (VEX/CSAF) to give definitive automation signals for specific product families. Microsoft’s statement that Azure Linux “includes this open‑source library and is therefore potentially affected” is a precise, testable claim about the Azure Linux family. It is not a denial that other Microsoft artifacts might include the same upstream code.

• Product attestations are a positive signal and are useful for automation.
• The absence of an attestation for a product is not definitive proof that the product is unaffected.
• Customers and security teams must perform artifact-level verification across their estate (kernel version checks and module presence), particularly where Microsoft-provided kernels are in use outside explicit Azure Linux images (for example, WSL2 kernels, image repositories, Marketplace appliances).

Flagging uncertainty: Until Microsoft expands its published VEX/CSAF attestations, the question of exactly which other Microsoft artifacts are affected remains an operational uncertainty. That uncertainty is resolvable by inventory (kernel inspection) and vendor attestations.

---

Final recommendations (quick checklist for busy operators)​

• If you run Azure Linux images: treat them as in‑scope, apply Microsoft kernel updates immediately, and reboot.
• For every Microsoft-provided kernel artifact in your environment (WSL2, Marketplace, linux‑azure, AKS node images): run the detection checklist above and patch if the artifact maps to a vulnerable kernel.
• Use automation to map kernel package versions to vendor advisories and upstream commit fixes.
• Monitor kernel logs and I/O telemetry for signs of flush-related throttling and address incidents promptly.
• Maintain an internal inventory of all kernel-bearing artifacts; require image provenance and version checks before deployment.

---

Conclusion​

CVE‑2025‑38063 is a focused device‑mapper fix that corrects an unintended writeback throttling of flush bios carrying REQ_PREFLUSH. Microsoft’s public guidance correctly identifies Azure Linux as a Microsoft product that includes the upstream code and is therefore potentially affected, and Microsoft has committed to publishing CSAF/VEX attestations and expanding them if additional Microsoft artifacts are identified as carriers.
However, the attestation is scoped and phased: it is authoritative for Azure Linux but not a proof that no other Microsoft product includes the vulnerable device‑mapper code. Operators must treat Azure Linux as in‑scope now, inventory the rest of their Microsoft-supplied kernel artifacts, verify kernel versions and device‑mapper presence, and apply patched kernels or updated images. The operational posture that minimizes risk is simple and deterministic: verify, patch, and reboot where necessary — and automate those steps where possible.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center