CVE-2025-22126: Linux MD UAF Fix and Azure Attestation

A critical race-condition bug in the Linux kernel’s MD (Multiple Devices) subsystem — tracked as CVE-2025-22126 — was fixed upstream after researchers identified a use‑after‑free (UAF) that can occur when the kernel iterates the global list of md devices. The fix addresses a subtle iterator / reference-counting race in code paths used by shutdown and cleanup routines; Microsoft’s advisory language confirms Azure Linux as a publicly attested carrier of the affected upstream code, but that attestation does not, by itself, prove or disprove exposure in other Microsoft-delivered artifacts.

Background / overview​

The Linux MD subsystem (drivers/md) implements the software RAID and related “multiple devices” framework used by mdadm and userspace tooling. Vulnerabilities in MD are important because the subsystem runs in kernel context, is widely present in general-purpose kernels, and can be enabled in a range of builds from cloud images to embedded kernels. The CVE entry for CVE‑2025‑22126 describes a UAF triggered when md_notify_reboot() and md_exit() iterate the all_mddevs list while concurrent removal and free of the next list entry races with the iterator.
Technically, the problem arises from a classical race between: (a) a CPU iterating a linked list using a “safe” helper pattern, taking a reference on the current mddev and then releasing the list lock, and (b) another CPU removing and freeing the next mddev entry during that unlocked window. The result can be a dereference of freed memory when the first CPU resumes iteration and accesses the next entry’s fields. Upstream maintainers accepted a patch series that changes the iteration and adds a small helper to keep reference semantics safe.
The practical impact profile: local attack vector, low-privileged user access sufficient to trigger the code paths in many configurations, and potential for high confidentiality/integrity/availability impact depending on exploitation complexity and environment. Several distribution advisories and trackers recorded the CVE and the affected kernel ranges; upstream fixes landed in the stable trees and were backported by vendors.

---

What exactly was wrong — a concise technical explainer​

• The vulnerable loop originally used list_for_each_entry_safe() combined with reference-management calls (mddev_get() / mddev_put()) in a pattern that looked safe while holding the list lock.
• However, the code released the list lock between taking the reference to the current entry and continuing iteration, opening a narrow window where the next entry could be unlinked and freed by another CPU. If that happens, later dereference of the next entry’s fields produces a use‑after‑free.
• The upstream fix converts the iteration to a safer pattern and factors out a helper (mddev_put_locked() in the patch discussion) to ensure that mddev_put() cannot free an entry while another CPU expects its fields to exist. The maintainers’ discussion and patch notes document the race scenarios and the rationale for the chosen fix.

Why this matters in practice: use‑after‑free issues in kernel code often lead to memory corruption that can be used to crash kernels (denial of service), leak kernel memory, or — in more complex chains — escalate privileges or achieve arbitrary kernel code execution. Exploitability depends heavily on the build configuration, kernel hardening features (KASLR, SMEP/SMAP where applicable), and whether the vulnerable code path can be reached from an unprivileged context on a target system. Multiple vendor trackers assigned a non‑trivial severity rating and pushed patches in distribution kernels.

---

Who is affected: distributions, kernels, and Microsoft artifacts​

Several public vulnerability trackers and vendor advisories list kernel versions and distributions impacted by CVE‑2025‑22126. Upstream metadata (OSV/NVD) and distribution advisories show that the flaw affected multiple 6.x kernel ranges and that fixes landed in multiple stable branches. This means the vulnerability could appear in any kernel image built from an affected upstream commit range and including the MD subsystem (CONFIG_MD / CONFIG_BLK_DEV_MD) as either a built‑in or module.
Major Linux distributions and clouds responded with kernel updates or backports; for example, Amazon Linux documented affected kernels and published patch advisories, and several distributor trackers enumerated the fixed commit hashes used to remediate the issue. The definitive places to check for affected versions are vendor advisories and the upstream git commit history that identifies the exact commit(s) that introduce and fix the bug.
Microsoft’s public statement on its Security Update Guide for other Linux CVEs has a recurring FAQ paragraph that affirms Azure Linux as a product Microsoft has examined and attested to include the implicated open‑source component; Microsoft notes that it will update the CVE mapping if additional Microsoft products are later identified as including the same library or code. That language is an attestation of what Microsoft has inspected and reported — useful and authoritative for Azure Linux — but it does not guarantee exclusivity or imply that other Microsoft artifacts cannot also contain the same upstream code. Treat “attested” as “confirmed and published,” not as an exhaustive claim about every Microsoft image or kernel. (msrc.microsoft.com)

What this means for Microsoft products other than Azure Linux​

• Azure Linux: Microsoft has publicly attested that Azure Linux images were inspected and include the upstream code the CVE identifies, so Azure Linux customers should follow Microsoft’s update guidance as a priority. (msrc.microsoft.com)
• WSL2 (Windows Subsystem for Linux): Microsoft builds and ships a Microsoft‑tuned Linux kernel for WSL2. That kernel is based on upstream kernel sources and is serviced via Microsoft Update; whether a particular WSL2 kernel build contains the vulnerable MD code depends on the exact kernel version and kernel config used in that WSL image — it’s possible for WSL images to include MD support. Customers should not assume WSL2 is safe by implication; instead, verify the shipped kernel version and the kernel config for CONFIG_MD / CONFIG_BLK_DEV_MD.
• Azure Marketplace images, AKS node images, appliance images: Microsoft and third parties publish many different kernel artifacts. Because the MD code originates upstream and is reused in many builds, any Microsoft‑supplied artifact that includes a kernel in the affected commit range and enables MD could be impacted. Microsoft’s published attestation for Azure Linux is a strong signal, but it is not a technical proof that other Microsoft artifacts are not affected.

---

How to determine whether your systems are vulnerable​

• Identify kernel versions in your fleet. Check output from uname -r on each host and map the version to vendor advisories that list fixed ranges. Upstream trackers and OSV list the kernel version ranges involved; use those to triage quickly.
• Inspect kernel configuration for MD support. Look for CONFIG_MD or CONFIG_BLK_DEV_MD being set (built‑in =y or module =m). If MD is not enabled in a kernel build, the MD code paths cannot be triggered. Check /proc/config.gz, the kernel config file shipped with distributions, or the build config used to produce WSL/Azure images.
• For cloud images and containers, verify the image artifact (SBOM, package list, or kernel package metadata). Microsoft’s CSAF/VEX outputs (where available) and vendor SBOMs can accelerate triage by declaring whether a named product contains the implicated component. If Microsoft has published a VEX/CSAF entry for Azure Linux, that attestation should be used programmatically to mark Azure Linux images in‑scope for the fix. (msrc.microsoft.com)
• For WSL2 and vendor kernels, check the exact kernel commit or release string embedded in the WSL kernel build (the Microsoft WSL kernel source and the build tag are public in the WSL2 repo). Confirm whether the shipped build incorporates upstream commits that were fixed, or whether the build predates the upstream fix.
• If you operate a diverse fleet, perform artifact‑level scanning (image analysis, SBOM enumeration, and binary scanning) rather than relying solely on vendor product names. The same upstream file can be present in many different Microsoft and third‑party artifacts depending on how kernels were compiled and packaged.

---

Immediate mitigation and remediation steps​

• Priority action: apply vendor patches and kernel updates. Vendors and distributions that shipped affected kernels published fixes and advisories; update to the patched kernel release or apply the backported vendor patch and reboot nodes to load the patched image. Upstream commit IDs and distribution advisories provide the exact fixes to look for.
• If you cannot immediately update, reduce attack surface:
• Disable MD support by booting a kernel without CONFIG_MD or by blacklisting the MD module, if practical and if you do not rely on software RAID/LVM functionality.
• Restrict access to systems where an untrusted local user could trigger md code paths (e.g., shared build hosts, CI runners).
• Monitor for abnormal crashes or kernel oopses that could indicate attempts to trigger UAF conditions.
• Verify fixes:
• Confirm the running kernel version is a patched release (compare to vendor advisory lists).
• Confirm the vendor patched commit hashes or backport IDs are present in the kernel package or build metadata.
• Reboot into the patched kernel and reconfirm that the vulnerable commit range is not present.
• For Azure Linux customers: follow Microsoft’s update guidance for Azure Linux images and use the Microsoft‑supplied CSAF/VEX statements as part of your automated triage pipeline to mark images that Microsoft has confirmed include the affected upstream code. Microsoft has signaled that Azure Linux is their attested product for these Linux CVEs and will expand attestations if additional products are identified. That is an operationally useful signal — but it should be combined with artifact‑level verification for multi‑product environments. (msrc.microsoft.com)

---

Detection and monitoring guidance for security teams​

• Implement or run a targeted kernel config and version scan across the organization. Tools that harvest /proc/version, /boot/config-*, or the packaged kernel metadata can be scripted to detect in‑scope kernels rapidly.
• Use SBOMs and VEX/CSAF outputs where available. Microsoft and other vendors increasingly publish machine‑readable attestations; consume these programmatically to mark products as “attested vulnerable” vs. “not attested.” However, treat the absence of an attestation as unknown, not as a guarantee of safety. (msrc.microsoft.com)
• Watch for kernel oopses or repeated crashes on systems that use software RAID or LVM; the MD code paths are exercised by reconfigure/teardown workflows and reboot/exit routines, making kernel logs and crash telemetry useful early indicators of attempted exploitation.

---

Assessment: Microsoft’s wording — careful reading matters​

Microsoft’s Security Response Center (MSRC) wording that names Azure Linux as the product that “includes this open‑source library” must be read as an attestation of inspection and published mapping rather than an exclusivity claim. In operational terms:

• Positive: Microsoft confirming Azure Linux contains the component gives Azure Linux customers a clear, authoritative action item: update those images according to Microsoft guidance. That reduces uncertainty for that product family. (msrc.microsoft.com)
• Limitation: The wording does not guarantee that no other Microsoft product or artifact contains the same upstream code. Microsoft distributes a variety of Linux kernels and images (WSL2 kernels, Azure VM images, Marketplace appliances, AKS node images), and the presence of the same upstream code in those artifacts is an artifact‑level question. Until Microsoft publishes additional CSAF/VEX attestations for other products, customers must assume other artifacts could be carriers until they verify via SBOMs or image inspection.

In short: treat Microsoft’s attestation as authoritative and actionable where it applies, and treat its scope as product‑scoped rather than global.

---

Longer‑term operational recommendations​

• Automate artifact inspection: enforce SBOM generation and consumption for all images and kernel packages used in production. SBOMs make it possible to find library usage without waiting for vendor‑level attestations.
• Integrate VEX/CSAF feeds: where vendors publish machine‑readable VEX entries, feed those into ticketing and policy engines to automate triage and remediation priorities. Microsoft has begun publishing such attestations for Azure Linux and stated an intent to expand that program. (msrc.microsoft.com)
• Harden local user boundaries: restrict ability for low‑privileged users to access environments where kernel code execution paths like md might be exercised (CI runners, multi‑tenant dev boxes). Add host‑level controls to limit untrusted user access pending full patch rollout.
• Maintain a kernel build inventory: for environments that compile or ship custom kernels, keep a reproducible build inventory (tagged commits, config, and build artifacts). That makes it straightforward to decide whether a given kernel needs the upstream fixes applied or backported.

---

Final verdict and practical takeaway​

CVE‑2025‑22126 is a meaningful kernel UAF fix that landed upstream and has been incorporated into vendor advisories and distro kernels. Microsoft’s explicit attestation names Azure Linux as a product that includes the implicated code and therefore should be considered in‑scope for the fix; however, that attestation is product‑scoped and not a blanket statement about all Microsoft artifacts. Organizations must therefore:

• Treat Azure Linux images as confirmed in‑scope and update them according to Microsoft guidance. (msrc.microsoft.com)
• Conduct artifact‑level verification for other Microsoft‑supplied or Microsoft‑derived kernels (WSL2 kernels, Azure Marketplace images, AKS node images, appliances). Do not assume absence of an MSRC attestation equals safety.
• Apply vendor patches, update kernels, and reboot as appropriate; where immediate updates are impractical, consider temporary mitigations (disable MD support, restrict access, increase monitoring).

The good news is that the upstream fix is public and distribution vendors have published updates; the operational job now is fast, artifact‑level triage followed by prioritized patching and rebooting to eliminate the UAF window across your fleet.

---

Conclusion
CVE‑2025‑22126 is a serious kernel bug that required a surgical change to MD’s iteration and reference semantics. Microsoft’s public attestation that Azure Linux includes the affected upstream code gives Azure Linux customers a clear remediation path, but other Microsoft kernels and images should be validated independently. Treat vendor attestations as authoritative where they apply, but always combine them with SBOM‑based, artifact‑level verification to close blind spots in complex supply chains. Apply patches immediately, verify patched builds, and monitor kernel telemetry closely until every in‑scope artifact in your estate is confirmed remediated.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center