CVE-2025-22115 and Azure Linux Attestation: Which Microsoft Artifacts Risk?

Short answer (TL;DR)

• No — Azure Linux is the only Microsoft product Microsoft has publicly attested (via its MSRC/VEX/CSAF work) to include the upstream btrfs code for CVE‑2025‑22115 so far, but that statement is a scoped inventory attestation, not a proof that no other Microsoft‑distributed artifact contains the same code. Microsoft committed to expand its attestations and update the CVE if additional Microsoft products are found to ship the component.

Why that short answer — what Microsoft actually said, and what it doesn’t mean

• What Microsoft said: MSRC’s advisory language (and the MSRC blog about publishing machine‑readable VEX/CSAF attestations) explains that Microsoft has performed inventory work for the Azure Linux distribution and therefore can authoritatively state that “Azure Linux includes this open‑source library and is therefore potentially affected.” Microsoft also documented that it began publishing VEX/CSAF attestations starting with Azure Linux and will update CVE records if other Microsoft products are discovered to carry the same upstream component. That is an explicit, documented, phased transparency approach.
• What that wording does not mean: it is not a universal negative (“no other Microsoft product ships this library”). It is a per‑product attestation: Azure Linux is the product Microsoft has completed inventory for and therefore the one Microsoft can confidently mark as “known affected / under investigation / fixed” in machine‑readable VEX/CSAF. Absence of an attestation for some other Microsoft product is not proof that the product lacks the code — it may simply not yet have been inventoried/published. Independent verification of other Microsoft artifacts is still required.

Which other Microsoft artifacts/products could realistically include the same btrfs code?
(why you should not assume only Azure Linux is in-scope)

• WSL2 kernel images: Microsoft publishes and ships a Linux kernel image used by Windows Subsystem for Linux 2. That kernel is based on upstream Linux and is maintained as a Microsoft repo/build (WSL2‑Linux‑Kernel). Whether a particular WSL kernel build includes btrfs is a matter of kernel configuration and the exact kernel revision used; therefore WSL kernels could include the btrfs source paths and could be affected depending on build/version.
• Azure kernel packages / linux-azure / “kernel-azure”: Azure often ships cloud‑optimized kernels (linux‑azure or Microsoft‑built kernel packages) for some VM images. Those kernel artifacts can be compiled with or without btrfs and, if built from an upstream revision that predates the upstream fix, could be vulnerable until patched. Microsoft’s attestation focused on Azure Linux images specifically; other cloud kernel artifacts need separate verification.
• Marketplace / partner / curated VM images and AKS node images: Azure Marketplace images and partner‑supplied images are assembled from kernels and packages which may include upstream code. Microsoft’s single‑product VEX rollout means Marketplace images are not automatically covered by the Azure Linux attestation unless the publisher and Microsoft include them in the same attestation. Treat Marketplace/partner images as requiring independent verification.
• Container host kernels / custom appliance images: A container image does not contain the host kernel, but VM appliance images or statically bundled kernels that Microsoft distributes (or that run on Microsoft infrastructure) are in scope if the kernel inside them includes the btrfs code.
• Note on Windows core products: the Windows NT kernel does not ship Linux kernel code. A plain Windows desktop/server without WSL2 or third‑party Linux kernels is not affected by a Linux kernel btrfs bug. (Separate third‑party Windows drivers re‑implementing btrfs would be an independent project and must be evaluated separately.

Evidence and independent corroboration (what public sources show)

• Canonical upstream/NVD description of CVE‑2025‑22115 documents the bug/fix in the Linux kernel’s btrfs implementation (fs/btrfs/block-group.c) and the relevant upstream commit range; distributions and security trackers map which kernel versions are affected and which contain the fix. This provides the canonical technical basis for determining whether a given kernel build is affected.
• Microsoft’s MSRC blog announcing machine‑readable VEX/CSAF publication (October 22, 2025) explains Microsoft’s phased rollout (starting with Azure Linux), and that Microsoft will update attestations/CVEs for other products if additional product carriers are discovered. That blog is Microsoft’s public explanation of the process used to map third‑party CVEs to Microsoft products.
• Platform and distro advisories (SUSE, Ubuntu, Amazon/Red Hat trackers, OSV, etc. show downstream vendors mapping and patching the same CVE in their kernel packages — use those trackers to map package versions to upstream commit IDs. Those trackers are how you cross‑check whether a vendor/kernel package has included the fix or remains vulnerable.

What you (as an Azure/Windows customer or security owner) should do now — practical verification & mitigation steps
1) If you run Azure Linux images (the attested product)

• Follow Microsoft’s guidance and the Azure Linux (Azure Linux / CBL‑Mariner) updates and apply the vendor patches Microsoft publishes for the attested Azure Linux images. Microsoft’s VEX/CSAF attestation is authoritative for that product and will indicate affected/fixed status for specific image builds.

2) If you run any Microsoft‑distributed Linux kernel artifact (WSL2, linux-azure kernels, Marketplace images, AKS node images, Azure Stack appliances)

• Don’t assume they are unaffected just because they aren’t listed in the Azure Linux attestation. Instead:
• Identify the kernel used by the artifact (uname -r or the image’s package metadata).
• Check whether btrfs support is present in that kernel (see commands below).
• Map the kernel version/build to upstream commit(s) referenced by CVE‑2025‑22115 (NVD / distro trackers list the upstream commits and affected ranges).
• If you find the vulnerable code is present, patch the kernel or redeploy images updated by the vendor/MSRC.

3) Quick commands to check a live host or VM (run as appropriate for your environment)

• Check kernel version:
• uname -r
• Is btrfs present as a module or built in:
• lsmod | grep -i btrfs
• grep -i btrfs /proc/filesystems
• find /lib/modules/$(uname -r) -type f -name "btrfs.ko"
• Check kernel configuration (whether CONFIG_BTRFS is set as module or built-in):
• zcat /proc/config.gz | grep -i CONFIG_BTRFS
• grep -i CONFIG_BTRFS /boot/config-$(uname -r)
• If you have an image or kernel binary, inspect its build tags/changelog to map to upstream commit IDs — compare those commits to the upstream commit(s) that fix CVE‑2025‑22115 (NVD / distribution advisories list the commit IDs).

4) For WSL2 users and admins

• Microsoft publishes the WSL kernel source and configuration (WSL2‑Linux‑Kernel repo). If you run the Microsoft‑built WSL kernel (default), check the published WSL kernel source and config used for your Windows release and map it to the upstream commit that fixes CVE‑2025‑22115. If you run a custom WSL kernel, you are responsible for ensuring it contains the fix.

5) For Azure Marketplace / AKS / partner images

• Ask the image publisher for an SBOM / kernel build metadata or check the image’s published changelog. If the image is Microsoft‑maintained (and not yet listed in MSRC’s VEX), ask the publisher whether they have inventoried the artifact and if/when they will publish a VEX/CSAF attestation. Microsoft committed to expanding attestations but those are product‑scoped and phased; Marketplace/partner images need their own verification.

6) Use multiple trackers to validate fixes

• Use NVD and distro vendor advisories (Ubuntu, SUSE, Red Hat, Debian, Amazon Linux, OSV, etc. to map kernel package versions to the upstream commit(s) that fix CVE‑2025‑22115. If your kernel package has the fix, you’re covered; otherwise patch. Security trackers often list which package versions are fixed and provide vendor guidance.

Why Microsoft’s phrasing (“Azure Linux includes this open‑source library...”) is still useful

• The attestation is valuable: by starting VEX/CSAF publication with Azure Linux, Microsoft gives machine‑readable, authoritative inventory for that product. That reduces false positives for customers who run Azure Linux and lets them automate remediation decisions. But the attestation is per product family; the product mapping work must be repeated for other Microsoft artifacts and SKUs before Microsoft can make similarly authoritative statements about them.

Short checklist you can follow (operational checklist)

• Step 1 — Inventory: List all Microsoft‑supplied Linux artifacts you run (Azure Linux images, WSL2, Marketplace VM images, AKS node images, appliances).
• Step 2 — Verify kernel: For each artifact, run the commands above to detect btrfs presence/config, or obtain the kernel package metadata/SBOM.
• Step 3 — Map to upstream: Use NVD/distro advisories to map the kernel/package to upstream commit IDs that are fixed for CVE‑2025‑22115.
• Step 4 — Patch/replace: If the artifact is vulnerable, apply vendor patches or redeploy updated images. If a vendor‑supplied image doesn’t have a timely fix, consider temporary mitigations (remove/unmount btrfs volumes, restrict local access) while you wait for patched images.
• Step 5 — Monitor: Subscribe to MSRC advisories and the VEX/CSAF feed (Microsoft’s blog and provider metadata explain where VEX files are published) to be notified if Microsoft expands the attestation scope beyond Azure Linux.

Example phrasing you can use to query vendors / Microsoft support

• “For image X (or kernel package Y), please provide the kernel build metadata / SBOM or the kernel’s upstream commit IDs so we can verify whether CVE‑2025‑22115 (btrfs_create_pending_block_groups refcount race) is present and whether your build includes the upstream fix. If you have a VEX/CSAF attestation for this product, please point me to the file.”

Concluding guidance (short)

• Treat Microsoft’s Azure Linux attestation as authoritative for Azure Linux (apply Microsoft’s updates there).
• Do not assume that attesting one product excludes other Microsoft artifacts from being affected. Any Microsoft artifact that ships a Linux kernel (WSL2, linux‑azure kernels, Marketplace images, AKS nodes, appliance images) can potentially include the same btrfs sources depending on kernel version/configuration; verify those artifacts individually.
• Use kernel inspection commands, vendor advisories, and Microsoft’s VEX/CSAF outputs to make a deterministic, evidence‑based determination for each artifact you run.

Primary references (selection)

• Microsoft Security Response Center (MSRC) blog about publishing machine‑readable VEX/CSAF (explains phased rollout starting with Azure Linux).
• NVD / upstream CVE record for CVE‑2025‑22115 (technical description, affected commit ranges).
• Microsoft documentation / Learn: WSL kernel release notes and the publicly maintained WSL kernel source (explains Microsoft publishes a Linux kernel for WSL2).
• Distribution and OSV advisories mapping the CVE and listing fixed package versions (SUSE / OSV / vendor trackers).

If you want, I can:

• Walk through how to check a specific image or VM you run (tell me the image name / uname -r output) and I’ll help map it to upstream commits and advisory data; or
• Pull the exact MSRC VEX/CSAF file(s) and the NVD entry for CVE‑2025‑22115 and show the commit IDs and the vendor mapping side‑by‑side.

Would you like me to check any specific Microsoft image/kernel (WSL, an Azure VM image, or an AKS node image) for btrfs presence and CVE exposure?

---

Source: MSRC Security Update Guide - Microsoft Security Response Center