Linux maintainers have pushed a fix for a serious use-after-free vulnerability in the kernel’s MD (Multiple Devices) subsystem that could allow local users to crash systems or escalate privileges. Tracked as CVE-2025-22126, the flaw has already been confirmed in Microsoft’s Azure Linux distribution, and while WSL2 kernels have not been explicitly named, they could be affected depending on their build configuration.

A Subtle Race in Storage Code

The bug lives in the Linux kernel’s MD subsystem—the code that powers software RAID and the mdadm tool. When the kernel iterates over global list of md devices during shutdown or cleanup (md_notify_reboot() and md_exit()), it used a pattern that looked safe: grab a reference to the current device, release the list lock, then continue. But that lock-release window opened a narrow chance for another CPU to remove and free the next entry’s memory. When the first CPU later dereferences it, boom—a use-after-free (UAF).

Upstream maintainers fixed this by converting the loop to a safer iteration scheme and adding a helper (mddev_put_locked()) to keep reference counting tight. The patches landed in multiple stable kernel branches, and distributions have been backporting them swiftly.

A UAF in kernel space is no minor nuisance. It can lead to memory corruption, kernel panics (denial of service), information leaks, or—with enough craft—privilege escalation. The attack vector is local: a low-privileged user who can trigger the MD code paths could potentially exploit this. On shared hosts, CI runners, or multi-tenant machines, that’s a real concern.

Mapping the Impact: From Cloud to Desktop

Not every Linux box is vulnerable. The MD subsystem must be present and enabled (CONFIG_MD or CONFIG_BLK_DEV_MD). If you don’t use software RAID or LVM, your kernel might not even load that code. But distributions often ship kernels with MD built-in or as a module, and many cloud images enable it by default.

Here’s how the exposure breaks down for different audiences:

  • Azure Linux users: Microsoft has officially attested—through its Security Update Guide—that Azure Linux includes the affected open‑source component and thus falls under this CVE’s scope. That makes Azure Linux a top‑priority update target. Microsoft’s FAQ wording says they publish CSAF/VEX data for the distro and will update the CVE if other products are later identified. Treat this as a confirmed, in‑scope vulnerability.
  • WSL2 on Windows: Microsoft ships a custom Linux kernel for WSL2, based on upstream sources. That kernel often enables MD support. The company hasn’t (yet) published an explicit statement about WSL2 in this CVE, but the vulnerability is purely a question of whether the kernel build includes the affected code. Check your WSL2 kernel version—run uname -r inside WSL—and verify its config for MD. If you find it enabled, assume exposure until proven otherwise.
  • Other Microsoft‑supplied kernels: Azure Marketplace images, AKS node images, and various appliances often embed Linux kernels from upstream. Any of them could be vulnerable if they ship a kernel within the affected commit range with MD enabled. Microsoft’s attestation covers Azure Linux specifically; don’t extend that assurance to other artifacts without doing your own checks.
  • General Linux admins: All major distributions—Red Hat, Ubuntu, Debian, Amazon Linux, SUSE, etc.—have released advisories and patches. The vulnerability affects kernels in the 6.x series (including LTS versions like 6.1 and 6.6) and some earlier trees where the buggy code was backported. If you run a custom kernel, review the commit history to see if you’re within the vulnerable window.

Verifying Exposure: Step‑by‑Step

  1. Check your kernel version. On any Linux host, run uname -r. Compare the version string to your distribution’s security advisory. Most vendors list the exact kernel update that contains the fix. For upstream‑based kernels, the fixed commits hit multiple stable trees; look for a version that is at or above the patched release.
  2. Inspect the kernel configuration for MD. You can look at /boot/config-$(uname -r), /proc/config.gz, or the kernel’s build metadata. Search for CONFIG_MD or CONFIG_BLK_DEV_MD. If they are set to =y or =m, the vulnerable code is present (even if not actively used). If they are not set, the vulnerability cannot be triggered.
  3. For Azure Linux: Microsoft provides CSAF/VEX statements. Feed those into your vulnerability management pipeline to automatically flag affected images. The MSRC advisory page is the authoritative source for Azure Linux customers.
  4. For WSL2: Check your WSL kernel build tag. You can find it by running cat /proc/version or visiting Microsoft’s WSL2 kernel repository to compare the shipped build with the fixed commits. If the build date predates the upstream patch, consider updating via Windows Update or installing a newer kernel.
  5. Scan your fleet. Use SBOMs, image scanners, or a simple script that harvests kernel versions and configs from all your machines. Automating this step prevents blind spots, especially in mixed environments where some hosts run Microsoft‑supplied images and others run community builds.

What to Do Now

Patch immediately. That’s the primary remediation. Vendors have released kernel updates containing the fix. Apply them and reboot. For cloud instances, rolling node replacements or live‑patch services may let you avoid downtime, but a reboot is the surest way to load a clean kernel.

If you can’t patch right away:

  • Disable MD modules if you don’t need software RAID or LVM. Blacklist them with a kernel command line option (modprobe.blacklist=md_mod) or remove the md package. Be careful—this could break systems that rely on MD for root or data volumes.
  • Restrict local user access on vulnerable machines. Limit SSH, CI runners, and shared login environments while you plan the update.
  • Monitor for unusual kernel crashes. Repeated oopses or panics that reference md_* functions could be a sign of exploitation attempts. Gather crash dumps and investigate.

For Azure Linux customers, Microsoft’s attestation is a reliable go‑signal. Update your Azure Linux images and containers per the vendor’s guidance, and mark them as remediated once the new kernel is loaded.

For WSL2, if you find that your kernel is vulnerable, consider taking these immediate steps:

  • Run wsl --update to get the latest WSL2 kernel from Microsoft. Microsoft often bundles kernel updates with WSL2 updates. Check the kernel version afterward to confirm.
  • If the update doesn’t yet include the fix, and you depend on WSL for sensitive work, consider disabling MD in your WSL kernel by recompiling with CONFIG_MD=n (advanced users only) or by restricting unprivileged users inside the WSL environment.

The Road Ahead

Vulnerability management in a world where Linux kernels run inside Windows, on cloud instances, and on IoT devices remains a multi‑vendor puzzle. Microsoft’s growing use of CSAF/VEX for Azure Linux is a positive step, but the silence on WSL2 and other artifacts reminds us that attestations are usually product‑scoped, not universal. Keep your kernel inventory current, automate artifact scanning, and treat vendor statements as part of—not a replacement for—your own triage process.

CVE‑2025‑22126 is a mid‑severity flaw that becomes high‑risk if you’re running MD on a multi‑user system. The fix is already out; now it’s your turn to roll it out and close the window.