Azure Linux CVE-2025-38444: Attestations and Per Artifact Risk

Microsoft’s short, product‑scoped attestation that “Azure Linux includes this open‑source library and is therefore potentially affected” is factually correct for Azure Linux — but it is not a technical guarantee that other Microsoft products cannot include the same vulnerable Linux kernel code; whether they do depends on per‑artifact kernel versions and build configurations and therefore requires artifact‑level verification or an explicit Microsoft attestation.

---

Background / Overview​

On July 25, 2025 the Linux kernel community recorded a fix for a memory‑leak bug in the RAID10 code path tracked as CVE‑2025‑38444. The defect lives in the md/raid10 code (drivers/md/raid10.c) and occurs when the raid10 request path allocates memory from a mempool but fails to free it in a particular code path when the REQ_NOWAIT flag is set — producing an unreferenced allocation and a growing memory footprint under certain workloads. The kernel‑side announcement and commit set are published by the upstream maintainers. NIST’s NVD entry lists the vulnerability, describes the failing backtrace, and records a CVSS v3.1 base score of 5.5 (attack vector: local; impact category: availability). Several downstream trackers (Linux distributors and CVE aggregators) list the same description and map the upstream commits into distribution kernels. Microsoft’s Security Response Center (MSRC) entry for the CVE contains the now‑familiar short attestation line: “Azure Linux includes this open‑source library and is therefore potentially affected.” Microsoft has also documented a phased rollout of machine‑readable CSAF/VEX attestations (starting with Azure Linux) and committed to update CVE mappings if additional Microsoft products are identified to ship the same upstream component. That wording is accurate as a product‑scoped inventory result, and it matters because it provides a deterministic automation signal for customers who run Azure Linux images.

---

The technical story: what CVE‑2025‑38444 actually is​

What the bug does (concise)​

• Component: Linux kernel — md/raid10 (file: drivers/md/raid10.c).
• Fault: When raid10_read_request or raid10_write_request registers a new request and the REQ_NOWAIT flag is set, the code can allocate memory from a mempool but fail to free that allocation in the error/exit path.
• Observable symptom: kmemleak/unreferenced allocations or kernel diagnostic traces showing “unreferenced object …” from the mempool, and potential kernel warnings or gradual memory pressure on hosts that exercise the path heavily (e.g., fio, direct io, io_uring workloads).
• Practical impact: Availability / robustness — memory leakage that can accumulate and ultimately cause OOM conditions, kernel instability, or degraded service on long‑running or I/O‑heavy systems.

This description is the same text used by the kernel‑CVE announcement and repeated across distribution advisories. The kernel team published the specific upstream fix with commit links that maintainers can cherry‑pick or vendors can backport; the community recommends updating to a fixed stable kernel release rather than attempting ad‑hoc cherry‑picks.

Severity and exploitability​

• The vulnerability is local in nature (requires a local process that can drive block I/O through the md/raid10 code).
• There is no public evidence that the flaw enables remote code execution or privilege escalation by itself — its real world impact is a denial‑of‑service / reliability issue when the leak is triggered repeatedly.
• NVD and several distributors assign a medium severity classification with a CVSS base score of 5.5.

---

Why Microsoft singled out Azure Linux — and what that phrasing means​

Microsoft’s statement that Azure Linux includes the open‑source library and is therefore potentially affected is an attestation of inventory for a named product family, not a blanket claim about all Microsoft artifacts.

• Authoritative for Azure Linux: Microsoft has completed an inventory for the Azure Linux product family and found the upstream md/raid10 source in those published images; the attestation tells Azure Linux customers to treat those images as in‑scope and to apply the vendor’s remediation guidance.
• Not a proof of exclusivity: The statement does not prove that other Microsoft products (for example, WSL2 kernels, linux‑azure kernel builds used by some VM SKUs, Microsoft‑packaged Marketplace images or appliances, AKS node images, or other Microsoft‑distributed kernel artifacts) cannot include the same upstream code. Whether any given Microsoft artifact includes raid10 depends on the artifact’s kernel version, the kernel configuration (CONFIG_MD_RAID10 compiled in or as a module), and whether the artifact actually bundles or enables the md/raid code at build time. Absence of an explicit Microsoft attestation for another product is absence of attestation, not proof of absence.

Microsoft’s public CSAF/VEX rollout — which began with Azure Linux in October 2025 — intentionally publishes product‑level attestations first for a high‑value, widely deployed product family. That phased approach is pragmatic, but it creates a verification duty for organizations that run other Microsoft artifacts: you must either rely on Microsoft’s future attestations or verify the artifacts yourself.

---

Are other Microsoft products potentially affected?​

Short answer: Yes — potentially. Azure Linux is the only Microsoft product Microsoft has publicly attested (so far) to include the implicated md/raid10 source for this CVE, but other Microsoft‑supplied images and kernels could include the same code depending on build choices. You should treat the attestation as authoritative for Azure Linux, and treat other Microsoft artifacts as unverified until they are either attested by Microsoft or inspected directly.
Examples of Microsoft artifacts that could, in principle, carry the same upstream code:

• The Microsoft‑maintained WSL2 kernel (the published WSL kernel source and binary).
• linux‑azure / kernel‑azure builds used for some Azure VM image families.
• Azure Marketplace and partner images published by Microsoft that bundle a kernel.
• AKS node images or other managed images that include Microsoft‑packaged kernels.
• Microsoft‑branded appliances or management nodes that embed a Linux kernel.

Whether any of the items above actually includes the vulnerable code depends on their kernel version and CONFIG_* settings; the presence of the md/raid10 source is an artifact‑level property, not a product‑level inevitability. The correct defensive stance is to verify artifacts or wait for Microsoft to expand its VEX/CSAF attestations.

---

How to verify whether a Microsoft artifact in your environment is affected​

Below is a prioritized, operational checklist to establish exposure across Microsoft‑supplied artifacts.

1. Inventory all Microsoft‑supplied artifacts you run​

• Identify VMs and images where the publisher is Microsoft.
• List Windows hosts that run WSL2 and any custom WSL kernels.
• Enumerate Azure Marketplace images, AKS node pools, and Microsoft‑published appliances.

2. Determine the kernel version and configuration on each artifact​

Use these commands (run as root or with appropriate privileges):

• Basic kernel identity:
• uname -a
• cat /proc/version
• Kernel config (if present):
• zcat /proc/config.gz | grep CONFIG_MD_RAID10
• grep CONFIG_MD_RAID10 /boot/config-$(uname -r) || true
• Module / file checks:
• lsmod | grep raid10
• modinfo raid10 || true
• find /lib/modules/$(uname -r) -type f -name 'raid10' -print

If CONFIG_MD_RAID10 is set to m (module) or y (built‑in), the md/raid10 code is present. If it is not set, the artifact is not carrying raid10 and therefore cannot be affected by this particular code path.

3. Inspect image layers or SBOMs​

• For container images and marketplace appliances, extract the filesystem and inspect /boot/config-*, /lib/modules, or the kernel binary.
• If Microsoft provides VEX/CSAF/CSAF‑VEX files for the product, consume those machine‑readable attestations and map them against your inventory. Microsoft has started publishing VEX/CSAF attestations with Azure Linux and pledged to extend coverage; the VEX outputs are the authoritative vendor attestations when available.

4. Check kernel logs and diagnostics for evidence of the issue​

• Search kernel logs for kmemleak/unreferenced mempool traces or the backtrace pattern recorded in NVD (strings such as “unreferenced object” or the raid10_make_request backtrace).
• Example: journalctl -k | grep -i 'unreferenced object|raid10_make_request' or dmesg | grep -i 'unreferenced object'

If you observe repeated unreferenced allocations that map to raid10 under heavy I/O, treat the host as potentially impacted until patched.

5. Map to fixed kernel packages​

• Use the upstream commit references in the kernel‑CVE announcement and compare to your kernel’s commit list or your distribution’s patch mapping. Upstream commit URLs were published with the kernel announcement and are the canonical fixes to look for. If your vendor’s fixed kernel version includes those commits (or their backports), you are patched.

---

Mitigation and remediation guidance​

Preferred remediation (recommended)​

• Apply vendor kernel updates that include the upstream raid10 fix and reboot hosts. This is the simplest and most reliable approach for affected images and kernels; distribution maintainers and cloud vendors will publish patched kernel packages or image updates once they have integrated the fix. The kernel community recommends upgrading to a fixed stable release rather than attempting to piece together individual commits.

If you cannot immediately patch​

• Temporarily limit access to the affected hosts to trusted workloads only, and avoid exposing block device operations to untrusted tenants or users.
• If raid10 is provided as a module and the host does not require RAID10 functionality, consider removing/unloading the module (modprobe -r raid10) as a short‑term mitigation — but test carefully: unloading a module on a system using RAID10 can break storage.
• Apply operational compensations: isolate I/O‑intensive workloads, implement rate limits, and monitor for kernel log patterns indicating unreferenced mempools.

Detection and monitoring​

• Set alerts for kernel log entries containing the kernel backtrace fragments or “unreferenced object” strings tied to raid10_make_request.
• Monitor memory usage trends on hosts that use RAID10 under heavy I/O (e.g., fio, direct I/O, io_uring) to detect slow memory growth that might indicate an accumulating leak.

---

Practical enterprise checklist (quick response playbook)​

• Prioritize VMware/physical hosts and Azure VMs running Azure Linux images first — Microsoft has attested those images as potentially affected. Apply updated Azure Linux images or kernel packages per Microsoft guidance.
• Inventory all Microsoft‑provided kernel artifacts in your estate (WSL2, linux‑azure builds, Marketplace images, AKS nodes).
• For each artifact, run the kernel configuration and module checks listed above. Record results in your vulnerability management system.
• Where affected, schedule kernel updates and reboots in a maintenance window. For cloud‑hosted images, apply vendor image updates and redeploy nodes where necessary.
• If you cannot patch immediately, implement compensating controls, and set log/metric alerts for leak symptoms.
• Subscribe to MSRC VEX/CSAF outputs for Azure Linux and monitor for Microsoft updates expanding product coverage.

---

Risk analysis and critical assessment​

Strengths of Microsoft’s approach​

• Transparency for Azure Linux: Microsoft’s attestation is useful and unambiguous for customers who run Azure Linux — it provides a clear, machine‑readable automation signal to prioritize remediation for that product family. Publishing VEX/CSAF outputs is an industry‑best practice for vendor transparency and automation.
• Upstream correctness: The kernel team’s fix is small and surgical, and maintainers provide commit references to be backported into vendor kernels; the remediation path is straightforward once vendors map the fix.

Remaining risks and gaps​

• Attestation coverage is phased: Microsoft’s VEX/CSAF rollout began with Azure Linux and will expand; until Microsoft publishes attestations for other product families, organizations must verify artifact inventories themselves. The phased rollout creates a window where product owners might assume “no attestation = no problem,” which is incorrect.
• Artifact fragmentation across Microsoft: Microsoft builds and distributes multiple kernel artifacts with different build pipelines and configuration choices (WSL2 kernel, kernel‑azure, Marketplace SKUs, appliances). Any of those could carry md/raid10 depending on how they were built. Without per‑artifact attestation or direct inspection, definitive statements about other Microsoft products are not possible.
• Operational complexity of backporting: While upstream fixes are small, large vendors often need to test backports across numerous kernel branches and platform matrices before releasing updates; that can delay availability of vendor‑packaged fixes.

What we can verify (and how we verified it)​

• The vulnerability description, affected file, and the upstream commit references were verified against the Linux kernel CVE announcement (linux‑cve‑announce) and mapped CVE trackers. The kernel announcement shows the affected file (drivers/md/raid10.c) and provides the commit links to the stable tree fixes.
• Severity and the CVSS score were checked against NVD and distributor trackers; NVD lists a CVSS v3.1 base score of 5.5 for CVE‑2025‑38444.
• Microsoft’s phrasing and the policy to publish CSAF/VEX starting with Azure Linux were confirmed in Microsoft‑focused advisories and vendor‑attestation commentary in the public record; the phrasing reflects a per‑product inventory for Azure Linux and a commitment to expand coverage.

Any definitive claim that a specific other Microsoft product is or is not affected requires either (a) a Microsoft VEX/CSAF attestation naming that product as Known Affected / Not Affected / Fixed, or (b) direct artifact inspection by the operator. Until one of those is present, the only defensible posture is to treat other Microsoft artifacts as unverified and to perform the checks above.

---

Final recommendations for WindowsForum readers and IT teams​

• Treat Azure Linux images as confirmed in‑scope per Microsoft’s attestation; prioritize patching those images and kernels.
• Run the artifact verification checklist immediately for other Microsoft kernels you run (WSL2, linux‑azure, Marketplace images, AKS nodes).
• Patch quickly where the md/raid10 code is present; if patching is delayed, apply compensating controls and monitor kernel logs for the telltale mempool traces and unreferenced object messages.
• Subscribe to MSRC VEX/CSAF feeds and your distribution’s security advisories so you get automated notices when Microsoft expands attestations to other product families.
• Incorporate these verification steps into your CI/CD and image‑build pipelines so future vulnerabilities can be triaged systematically by artifact rather than by vendor‑level assumption.

---

Conclusion​

The MSRC wording that “Azure Linux includes this open‑source library and is therefore potentially affected” is an accurate, product‑scoped attestation: Azure Linux customers must treat their images as in‑scope and remediate accordingly. However, that sentence is not a technical guarantee that no other Microsoft product could ever include the vuln‑containing md/raid10 code; such inclusion is determined at the artifact build level (kernel version and CONFIG_* choices), and absence of attestation for other Microsoft products is not proof those products are safe. Operators should therefore (1) patch Azure Linux images per Microsoft guidance immediately, (2) inventory and inspect other Microsoft artifacts for CONFIG_MD_RAID10 or the presence of raid10 modules, and (3) monitor kernel logs for unreferenced mempool traces while waiting for vendor‑packaged fixes or Microsoft to expand VEX/CSAF attestations.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center