CVE-2025-38445: Azure Linux Attestation and the MD RAID1 Patch

The Linux kernel vulnerability tracked as CVE‑2025‑38445 — “md/raid1: Fix stack memory use after return in raid1_reshape” is real, narrowly scoped, and — crucially for Microsoft customers — Microsoft has publicly attested only one of its product families as a confirmed carrier of the vulnerable upstream code: Azure Linux. That attestation is authoritative for Azure Linux artifacts, but it is not a blanket claim that no other Microsoft product can or does contain the same md/raid1 code. Microsoft’s wording is a product‑level inventory statement (not an absolute exclusivity guarantee), and security teams should treat it accordingly: Azure Linux is confirmed as “potentially affected,” while other Microsoft SKUs remain an operational unknown until Microsoft or independent inspection confirms otherwise.

---

Background / Overview​

CVE‑2025‑38445 describes a correctness bug in the kernel md/raid1 reshape path: a local mempool object (newpool) was created on the stack and then copied into a persistent structure without properly reinitializing its wait list. That left conf->r1bio_pool.wait.head pointing at a stack address that becomes invalid once the function returns, and subsequent code paths that access that wait list can dereference an invalid address and trigger a kernel panic. The upstream fix reinitializes the persistent pool’s wait list after assignment, avoiding use of transient stack state later in normal I/O or cleanup paths. The vulnerability and the upstream patch are recorded in the kernel stable commit trees and public vulnerability databases. Why it matters operationally: this is a local kernel reliability and availability defect. A malformed or mis-timed code path can cause a panic (host crash), which on production storage systems can equate to a high‑impact outage. Most public trackers classify the issue as a stability/availability problem rather than a privilege‑escalation or remote code‑execution primitive.

---

The technical snapshot — what CVE‑2025‑38445 actually is​

The bug in plain language​

• The code in raid1_reshape allocated a mempool_t object on the stack (local variable).
• The code then copied that mempool value into a field that persists beyond the function call (conf->r1bio_pool).
• The mempool’s wait list (pool.wait.head) therefore pointed at stack memory that vanishes after function return.
• Later code that wakes or inspects that wait list may dereference that stale pointer and cause a kernel panic.

The fix​

• After assigning the newpool into conf->r1bio_pool, the code reinitializes conf->r1bio_pool.wait so the persistent pool’s wait list points to stable kernel structures instead of a transient stack address.
• The patch is small, surgical, and has been merged into multiple stable kernel trees (the upstream commit and stable‑tree backports are publicly logged).

---

Microsoft’s public statement and what it means​

Microsoft’s Security Response Center (MSRC) entry for this CVE (and many other kernel CVEs in 2025) includes a short FAQ item: “Is Azure Linux the only Microsoft product that includes this open‑source library and is therefore potentially affected by this vulnerability?” Microsoft’s answer emphasizes that Azure Linux is kept up to date and that Microsoft began publishing machine‑readable CSAF/VEX attestations in October 2025; the entry states that if additional Microsoft products are identified as carriers, the CVE will be updated. In short: Azure Linux = attested affected product; Microsoft will expand that attestation set as inventory work continues. That exact phrasing — which many administrators have seen before — is deliberate. A VEX/CSAF attestation is a product‑level inventory result: it tells you what Microsoft checked and found inside the named product family (in this case, Azure Linux). It does not say Microsoft searched every binary, kernel image, Marketplace VM, or other product SKU and proved the component is absent everywhere else. The practical implication for defenders is straightforward: treat Azure Linux as confirmed in‑scope; treat other Microsoft artifacts as unverified unless and until they are either attested or manually inspected.

---

Is Azure Linux the only Microsoft product that could be affected?​

Short answer: No — not necessarily. Azure Linux is the only Microsoft product that Microsoft has published a VEX/CSAF attestation for so far, but other Microsoft‑distributed Linux kernel builds or images may also carry the same md/raid1 code depending on kernel version and build configuration.
Why this is true:

• Microsoft maintains multiple, separate Linux artifacts that can embed different kernel sources and configurations: Azure Linux (Microsoft’s cloud‑optimized distro), the linux‑azure kernel builds used by some Ubuntu/Canonical Azure images, the WSL2 kernel binary Microsoft ships as part of Windows, curated Marketplace images and partner VM images, AKS node images, and internal appliance kernels. Each is a separate build with its own CONFIG_* settings and backport history. Any of these artifacts could, in principle, include the md/raid1 sources that were fixed upstream.
• A VEX/CSAF attestation covers the product set it names, not every product a vendor ships. Microsoft’s CSAF/VEX rollout deliberately started with Azure Linux (October 2025) as a manageable initial scope; more products will be inventoried and attested over time. Absence of an attestation today is not proof of absence of the component tomorrow.

In other words: Azure Linux is the confirmed “yes”; other Microsoft artifacts are “unknown” until proven otherwise.

---

Practical verification: how to confirm whether your Microsoft artifact is affected​

If you operate workloads that run Microsoft‑published or Microsoft‑curated Linux kernels (Azure VM images, AKS, Marketplace images, WSL2, or Azure Linux), use a combination of vendor attestations and direct artifact inspection. Follow these steps:

1. Check Microsoft’s VEX/CSAF and MSRC advisory for the CVE to see which Microsoft products are explicitly attested as affected. Microsoft will update the CVE record as it expands inventory.
2. For an Azure VM or image:
   • Identify the kernel package in the image (for Debian/Ubuntu: apt list linux-image*; for RHEL derivatives: rpm -qa kernel*).
   • Check distro vendor advisories (Ubuntu, RHEL, SUSE) for kernel packages that include the upstream fix (they map upstream stable commit IDs to package versions).
   • If you run Canonical’s linux‑azure or Microsoft‑optimized kernels, confirm the package changelog and version include the stable commit that reinitializes conf->r1bio_pool.wait.
3. For WSL2 on Windows:
   • Identify the WSL2 kernel build shipped on your system (wsl --status for WSL settings; check the kernel version with uname -a inside WSL).
   • WSL’s kernel is a Microsoft‑maintained Linux build; whether it includes md/raid1 depends on the exact build and CONFIG options. If uncertain, check the kernel config (/proc/config.gz if present) or query the WSL release notes for the kernel build. If a WSL kernel includes md/raid1 sources, it could be susceptible; if not, it is not. This is a per‑artifact check — there is no single global “WSL is safe” answer.
4. For Marketplace images and partner appliances:
   • Treat the image’s kernel as an independent artifact. Ask the image publisher for VEX/CSAF attestations or inspect the shipped kernel package and config.
5. Hunt for runtime indicators:
   • Look for kernel logs, dmesg, or oops/panic traces referencing md/raid1, mempool, or raid1_reshape.
   • Monitor for unexplained kernel panics on hosts that manage software RAID via mdadm. Those symptom patterns are consistent with this bug if the vulnerable md/raid1 code path is present.

---

Recommended operational actions for administrators​

• Treat Azure Linux images as priority: if you run Azure Linux, Microsoft has attested the product as “potentially affected.” Patch the kernel images or apply the vendor package that includes the upstream commit restoring safe pool initialization. Reboot into the patched kernel as required.
• Inventory Microsoft‑supplied kernel artifacts you rely on:
  • Azure VM images (identify image publisher and kernel package).
  • WSL2 kernel versions distributed to Windows endpoints.
  • AKS and Marketplace images used in your environment.
  • Any Microsoft curated or partner images in your supply chain.
• If you cannot patch immediately:
  • Restrict exposure: limit untrusted local access to machines that run software RAID; restrict who can manipulate md devices or run mdadm reshape operations.
  • Increase monitoring for kernel panics and md subsystem errors.
  • Use vendor livepatching when available and validated for the CVE (some distributions offer livepatch services that may cover stability fixes).
• Validate vendor packages:
  • When a distribution claims a kernel update fixes the issue, validate by confirming the package changelog includes the upstream commit IDs or the stable-tree backport that implements the mempool reinit change. The upstream commit is published in stable commit lists and can be cross‑checked against vendor changelogs.

---

Critical analysis — strengths, limitations and residual risks​

Strengths of the public response​

• The upstream remedy is a small and targeted fix that reinitializes the persistent mempool wait list — a surgical change with a low regression surface that is straightforward to backport into stable vendor kernels. The patch’s presence in multiple stable trees shows maintainers accepted the change and pushed the fix to long‑term branches.
• Microsoft’s adoption of machine‑readable CSAF/VEX attestations increases transparency: for the first time large vendors can publish per‑product attestations that state whether a given artifact contains an upstream flywheel of code. This reduces ambiguity for customers when an upstream CVE touches a shared OSS component shipped in many artifacts. Microsoft started this VEX rollout with Azure Linux in October 2025 and will expand coverage over time.

Risks and caveats​

• VEX/CSAF attestation coverage is phased and not exhaustive at launch. Microsoft’s Azure Linux attestation is authoritative for those artifacts, but the absence of attestations for other Microsoft products is an inventory gap, not definitive evidence of absence. Security teams must not convert “not yet attested” into “not affected.”
• Microsoft ships many separate kernel artifacts (Azure‑targeted kernels, WSL2 kernels, Marketplace images). Whether any one of them includes md/raid1 is a per‑artifact, build‑time property governed by kernel version, applied backports, and selected CONFIG_* options. This complicates automated triage unless the vendor publishes explicit attestations for each artifact.
• Real‑world impact depends on local exposure: the CVE requires code paths manipulating md/raid1 internals. Desktop Windows systems that do not ship a Linux kernel are not affected; but Windows machines that run WSL2 (which does ship a kernel) or teams running Azure Linux images on VMs must verify their artifacts. This nuance can be easily misunderstood in operational communications.

Unverifiable claims to flag​

• Public registry entries and vendor advisories document the fix and show the patch backports, but unless Microsoft explicitly attests another product (or you independently inspect the artifact), statements about which other Microsoft products include the vulnerable md/raid1 code are unverifiable. Treat such claims as “possible until proven otherwise” and proceed with artifact‑level verification.

---

A short playbook — step‑by‑step for WindowsForum readers (actionable checklist)​

1. If you run Azure Linux: schedule the vendor‑recommended kernel update immediately and reboot into the patched kernel. Azure Linux is explicitly attested as potentially affected.
2. Inventory hosts that run Microsoft‑distributed Linux artifacts (linux‑azure kernels, Marketplace images, AKS node images, WSL2 instances). Use uname -r, package manager queries, and vendor package names to map kernels back to vendor advisories.
3. Cross‑reference vendor advisories (Ubuntu, RHEL, SUSE, Canonical linux‑azure) to identify kernel packages that include the upstream stable commit(s) for the raid1 mempool fix. Confirm the upstream commit ID appears in the package changelog when possible.
4. If you operate multi‑tenant or cloud build hosts: treat these as higher priority. Exposed automation (CI that mounts images, image ingestion pipelines, or guest containers that can manipulate device‑mapper) increases the practical attack surface.
5. If you cannot immediately patch: restrict access to device‑mapper and /dev/md* nodes, remove CAP_SYS_ADMIN from untrusted containers, and stop scheduled reshape/resize operations until patched.
6. Monitor kernel logs for md subsystem panics or wake/wait errors tied to mempool or raid1 functions; preserve logs if a host panics for post‑mortem.

---

Final assessment and reading of Microsoft’s statement​

Microsoft’s advisory that “Azure Linux includes this open‑source library and is therefore potentially affected” is accurate as a product attestation and is useful: it tells Azure Linux customers they must patch. But it should not be read as proof that other Microsoft products are necessarily free from the same upstream code. The right operational posture is to combine vendor attestations with targeted artifact inspection: prioritize patching the attested product (Azure Linux), inventory other Microsoft artifacts you rely on, and verify those artifacts either via published VEX/CSAF attestations or direct inspection of the shipped kernel build and configuration. Microsoft’s VEX rollout (started October 2025) will reduce this uncertainty over time by publishing more per‑product attestations — until then, defenders must treat “not attested” as “unverified.”

---

CVE‑2025‑38445 is a small but impactful correctness bug in the RAID1 reshape code; the upstream fix is straightforward and widely backported. Azure Linux customers should assume they are in‑scope and apply vendor updates. Operators of other Microsoft‑supplied Linux artifacts should not rely on silence — instead, inventory, inspect, and patch based on kernel package mappings and published attestations. The combination of surgical patching upstream and Microsoft’s growing VEX/CSAF program improves clarity, but until coverage is comprehensive, pragmatic artifact‑level verification remains necessary for robust risk management.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center