CVE-2025-37856: Azure Linux Exposure and Verifying Microsoft Artifacts

Short answer (straight to your question)

• No — “Azure Linux” is not provably the only Microsoft product that can contain the vulnerable btrfs code. It is the only Microsoft product Microsoft has publicly mapped and attested (via its VEX/CSAF output / Security Update Guide) to include the upstream btrfs code that is the subject of CVE‑2025‑37856 at the time of Microsoft’s disclosure. However, that attestation is a scoped inventory statement (authoritative for the Azure Linux family) and not a universal proof that no other Microsoft artifact or image includes the same vulnerable code.

Executive summary (what this means for you)

• Microsoft’s public advisory and VEX/CSAF attestations identify Azure Linux as a known product that includes the affected kernel component for CVE‑2025‑37856; customers running Azure Linux should treat Azure Linux as “in-scope” and apply the vendor-supplied updates.
• Other Microsoft products (WSL kernels Microsoft ships, Azure Marketplace images, curated containers, appliances and any Microsoft-built artifacts that embed or ship kernel images) could also include the same upstream btrfs code depending on how those artifacts were built — but Microsoft has not (yet) published attestations mapping those SKUs to this CVE. That absence is not the same as a guarantee of “not affected.” You should verify any other Microsoft artifacts you run instead of assuming they are safe.
• Independent trackers (NVD, OSV, distro advisories) attribute CVE‑2025‑37856 to a btrfs list/race hardening fix in upstream kernel sources; those resources list the kernel commits and flag distributions that have fixed or tracked the issue. Use those upstream commit IDs plus your artifact’s kernel build metadata to map exposure.

Detailed technical and operational analysis
1) What CVE‑2025‑37856 actually is (short technical recap)

• The CVE describes a race condition in the Linux kernel’s BTRFS code that can lead to an inconsistent block_group::bg_list manipulation and premature decrements of a block group’s reference count. If triggered, the race can cause a refcount underflow and kernel WARNINGs / instability. The upstream fix hardens list_del/list_del_init usage and related list operations in the btrfs block-group code.

Why this matters

• BTRFS is a filesystem component in the kernel. A kernel‑level WARNING or crash is a denial‑of‑service (availability) event for the host; an exploitable kernel bug can have higher impact, but the public advisories for this CVE describe a race that causes refcount underflow and WARNINGs (typically leading to instability/DoS), not a remote code‑execution pattern. Public severity listings (NVD/OSV) show this as medium and often classify impact as availability.

2) What Microsoft actually said (and the exact interpretation)

• Microsoft’s update guide entry for CVE‑2025‑37856 (and the accompanying VEX/CSAF outputs Microsoft began publishing in October 2025) states Azure Linux includes the relevant open‑source library and is therefore potentially affected, and that Microsoft will update the CVE/VEX if additional Microsoft products are identified. That language is an attestation about the inventory Microsoft has completed and published so far — authoritative for the product(s) Microsoft lists, but explicitly phased: they promise to expand the VEX/CSAF mappings as further internal inventories are completed.

Important nuance (why “named = attested” ≠ “only”)

• A product-level VEX/CSAF attestation is Microsoft saying: “We checked this product family and found the component; here’s the status.” It is not a global search of all Microsoft artifacts performed and exhaustively proven to be clean. Large vendors commonly publish attestations in waves (start with a logical product family, then expand). Until Microsoft publishes an attestation for another product, that product’s status is simply “not yet published” (or “under investigation”), not a cryptographically enforced proof of absence.

3) Where else the same code could appear inside the Microsoft ecosystem (and therefore why you must not assume “only Azure Linux”)

• WSL2 kernel image(s): Microsoft publishes and maintains a WSL kernel source tree and periodically publishes WSL kernel builds. Depending on the WSL kernel configuration and build-time choices, btrfs may be built-in or modular. If the WSL kernel was built with btrfs enabled (CONFIG_BTRFS_FS or related), it could contain the same vulnerable code. You must inspect the WSL kernel config or the kernel package used for your WSL instance to be sure.
• Azure Marketplace images / curated VM images: Microsoft hosts many VM images in Azure (Azure Linux, partner images, marketplace images). Some of those images include Microsoft-built kernels or preinstalled distributions; whether they include btrfs depends on the distro and kernel package that the image includes. The Azure Linux VEX attestation applies only to the Azure Linux images Microsoft lists, not to every marketplace image.
• AKS/managed node images and curated containers: Node images used by AKS or curated container images may ship kernels, modules, or binaries that include the same upstream code. A vulnerable kernel module embedded inside an image counts as code in that artifact.
• Statically bundled or recompiled open‑source components: Some Microsoft artifacts (or third‑party marketplace artifacts they host) may include statically built components or custom kernel builds that embed old btrfs code even if system packages appear up to date. These need artifact‑level verification.

4) How to confirm whether a given Microsoft artifact (image, VM, WSL instance, container) is affected — a short triage checklist
Follow these verification steps (run on each type of artifact you depend on):
A. On a Linux VM / Azure Linux image

• Check whether the running kernel has btrfs support and whether a vulnerable kernel version is present:
  • uname -a (record vendor tag and kernel build)
  • zcat /proc/config.gz | grep -i CONFIG_BTRFS (or)
  • grep -i CONFIG_BTRFS /boot/config-$(uname -r)
  • lsmod | grep btrfs
  • findmnt -t btrfs
• Map your kernel version / build to upstream commits. Distribution advisories (Ubuntu, SUSE, Red Hat, Amazon Linux, etc. and the NVD/OSV entries list which upstream commits fix the issue — compare those upstream commit hashes with your kernel’s changelog or vendor changelog to decide if your kernel contains the fix.

B. For WSL2

• Inspect the WSL kernel you are running:
  • Check /proc/config.gz (if available) or the WSL kernel source and build config used by your WSL distribution.
  • Microsoft publishes the WSL2 kernel source and notes about config in their WSL repo — if you use the stock Microsoft WSL kernel, check Microsoft’s published WSL kernel config and any recent kernel package notes. If you built a custom WSL kernel, you are responsible for ensuring the kernel includes upstream fixes.

C. For Marketplace VM images, curated container images, or other Microsoft-supplied binaries

• Inspect the image manifest or the image’s package list. For containers, run a container shell and run the same kernel/package checks inside the node where that container runs; for VM images, check /boot/config-*, uname -a, and package changelogs. If the artifact is a prebuilt kernel image, compare vendor build metadata to upstream commits mentioned in NVD/OSV.

D. If the artifact is a Windows-hosted driver or a Windows reimplementation (e.g., WinBtrfs)

• This CVE concerns the Linux kernel btrfs implementation; Windows native drivers or reimplementations are separate projects and need independent vetting. Microsoft’s Azure Linux attestation covers Linux kernel packages, not unrelated Windows drivers. (If you depend on a Windows-side implementation of BTRFS, treat it separately.

5) Immediate mitigations and remediation guidance (practical)

• If you run Azure Linux images: apply the kernel updates Microsoft publishes for your Azure Linux channel as soon as those updates are available; Microsoft’s VEX/CSAF output and Security Update Guide are the authoritative mapping they publish for Azure Linux.
• If you run WSL2 stock kernels: confirm the WSL kernel build/config and update WSL if Microsoft publishes a patched WSL kernel build. If you run custom WSL kernels, rebuild with a kernel that includes the upstream fix.
• For Marketplace/partner images: inventory and inspect the kernel and packages inside each image; if an image contains a vulnerable kernel, replace or patch the image (rebuild and republish).
• If you cannot patch quickly: reduce attack surface:
  • Avoid mounting or using BTRFS filesystems on hosts that process untrusted workloads.
  • Isolate workloads that interact with BTRFS.
  • Restrict who can trigger filesystem operations (apply least privilege to users/processes).
  • Monitor kernel logs for WARNINGs associated with btrfs refcount issues and plan controlled restarts where necessary.

6) How Microsoft’s VEX/CSAF process changes the operational model (and what to watch)

• Microsoft publishes per‑CVE VEX/CSAF JSON files that state which Microsoft products have been inspected and their status (KnownAffected / Fixed / NotAffected / UnderInvestigation). Microsoft began publishing VEX attestations for Azure Linux in October 2025; they will expand attestations to additional products in phases. If you rely on a Microsoft product not present in VEX/CSAF for a CVE, your safest course is to treat that product as “requires verification” and perform the per-artifact checks above.

7) Evidence sources and how to use them for mapping

• Use these authoritative sources together to map exposure:
  • Microsoft Security Update Guide / MSRC VEX/CSAF for Microsoft product attestations and per‑product status for this CVE. (This is the authoritative vendor mapping for Microsoft products.
  • NVD and distro advisories (Ubuntu, SUSE, Red Hat, Amazon Linux trackers) to see vendor‑packaged fixes and CVSS context.
  • OSV and upstream kernel/git commits referenced in the OSV/NVD entries — use commit IDs to map whether your kernel build contains the upstream fix. (If your vendor's package changelog references the same commit, it is likely fixed in that package.

8) Practical example: mapping a kernel build to the upstream fix

• Step 1: find the upstream commit(s) that fix CVE‑2025‑37856 (OSV/NVD list commit hashes).
• Step 2: get your kernel package changelog / vendor package metadata and look for those commit refs or the vendor’s “fixed in kernel X.Y.Z” note. For Azure Linux, Microsoft’s VEX will point to the azl3 kernel versions it considers KnownAffected or Fixed.

9) What I cannot (responsibly) confirm for you

• I cannot assert that no other Microsoft artifact contains the vulnerable btrfs code unless Microsoft has published an explicit “Not Affected” or “Known Not Affected” attestation for that product/artifact. The only authoritative source for Microsoft product mappings is Microsoft’s own VEX/CSAF outputs; absence of a product from those outputs is a “not yet attested” state, not proof of absence. If you want me to check specific Microsoft images, kernel builds, or WSL kernel releases you use, provide the exact artifact names / kernel build strings and I will map them to upstream commits and public advisories.

References and sources (key authoritative links consulted)

• Microsoft Security Update Guide – CVE entry and product mapping for CVE‑2025‑37856 (Microsoft’s public advisory + VEX attestation statement).
• NVD entry for CVE‑2025‑37856 (technical summary and CVSS context).
• OSV.dev vulnerability entry with upstream commit references (useful to map the upstream kernel commits that fixed the race).
• Distro advisories and tracking pages (Ubuntu, SUSE, Amazon Linux) listing presence/fixes for the vulnerability — use these for vendor package mapping.
• MSRC blog on Microsoft’s VEX/CSAF program (Microsoft began publishing VEX attestations for Azure Linux in October 2025).

Recommended concrete next steps (prioritized)

1. If you run Azure Linux images (azl3 kernels): check Microsoft’s Security Update Guide and apply the Azure Linux kernel updates Microsoft publishes for CVE‑2025‑37856 immediately.
2. Inventory other Microsoft-supplied artifacts in your estate (WSL instances, AKS/VM node images, Marketplace images, curated container images) and for each artifact: collect kernel build strings (uname -a), kernel config (CONFIG_BTRFS presence), and package changelogs. Map those to upstream commit IDs listed in OSV/NVD.
3. If you run custom WSL kernels or custom kernels in images, rebuild and test with a kernel that includes the upstream fix.
4. Subscribe to Microsoft’s Security Update Guide / VEX feed for automated updates to the product mapping so that you receive immediate notice if Microsoft expands the attestation beyond Azure Linux.

If you want, I can — at no additional charge — do one of the following for you:

• Map a specific kernel build string (uname -a output or a kernel package name / version) to the upstream commits and tell you whether that kernel includes the fix. (Provide the kernel string or the VM image name.
• Produce a short script you can run across your estate (VMs, WSL hosts, container nodes) to automatically list candidates that have CONFIG_BTRFS enabled and to capture uname/config for mapping.
• Watch Microsoft’s VEX/CSAF for you (or produce a small monitoring recipe) and notify when Microsoft updates the CVE mapping for other Microsoft products.

Final practical takeaway

• Treat Microsoft’s Azure Linux attestation as an authoritative, high‑quality signal for Azure Linux images and patch those as directed. But do not let the wording “Azure Linux is known to include the library” lull you into assuming other Microsoft artifacts are free of the code. Perform per-artifact verification (kernel build + config + changelog mapping to upstream commit IDs) for any Microsoft-supplied image, kernel, or binary you run. If you share kernel build strings or image names, I’ll map them to the upstream commit/fixes and give you a definitive "affected / not affected / needs more data" answer.

Appendix — example commands (copy/paste)

• On a Linux VM (to gather data for triage):
  • uname -a
  • zcat /proc/config.gz | grep -i CONFIG_BTRFS || grep -i CONFIG_BTRFS /boot/config-$(uname -r)
  • lsmod | grep btrfs
  • findmnt -t btrfs
• For WSL (from an elevated PowerShell/WSL shell):
  • wsl --status (to see distro and kernel info)
  • In a WSL shell: uname -a ; zcat /proc/config.gz | grep -i CONFIG_BTRFS
• If you want the small script to run across many machines/agents, tell me which environment (Azure VMs via run-command, SSH fleet, or container hosts) and I will produce a tailored script.

— End —

---

Source: MSRC Security Update Guide - Microsoft Security Response Center