A Linux kernel bug in the Btrfs filesystem — tracked as CVE-2025-39779 — can cause write-ordering guarantees to be violated by prematurely clearing the PAGECACHE_TAG_TOWRITE tag on subpage folios, with downstream effects that include kernel assertions, crashes, and availability failures; Microsoft’s security page specifically names the Azure Linux distro as including the affected open-source component and says it will publish CSAF/VEX information and update the CVE if more Microsoft products are impacted.
Btrfs (the B-tree filesystem) is a sophisticated, copy-on-write Linux filesystem with features such as snapshots, checksums, built-in RAID, and per-subvolume management. The bug fixed by the CVE concerns the handling of subpage folios — units of the page cache used when filesystem block size is smaller than the kernel page size — and specifically the lifecycle of the PAGECACHE_TAG_TOWRITE (TOWRITE) tag during writeback. When writeback begins on a folio, the kernel must ensure that resources and ordering semantics are preserved until the folio is actually clean; the fix for this CVE ensures the TOWRITE tag is kept until the folio is cleaned, preventing ordering breakage. The public disclosure for CVE-2025-39779 was published on September 11, 2025; downstream vendor advisories and distro patch notices began appearing through September and October 2025 as maintainers incorporated the upstream fix into their kernels. The vulnerability carries a CVSS v3.1 base score of 5.5 in several vendor advisories, reflecting a local attack vector with no confidentiality or integrity impact but a meaningful availability impact when exploited or triggered (kernel oops/panic).
This premature clearing breaks higher-level ordering semantics. For example, btrfs relies on btrfs_wait_ordered_extents and related mechanisms to ensure that ordered write batches are completed before an operation that depends on ordering (such as truncation or synchronous fsync behavior). If pages are incorrectly marked as not TOWRITE while still dirty, other processes may not wait for those writebacks, causing race conditions, assertion failures, or unexpected file-system state during size or metadata operations. Upstream maintainers fixed this by introducing a variant that keeps the TOWRITE tag until the folio is actually clean (btrfs_subpage_set_writeback_keepwrite and only clearing the tag via a later xas-based operation.
Below are the key Microsoft touchpoints to consider:
Source: MSRC Security Update Guide - Microsoft Security Response Center
Background
Btrfs (the B-tree filesystem) is a sophisticated, copy-on-write Linux filesystem with features such as snapshots, checksums, built-in RAID, and per-subvolume management. The bug fixed by the CVE concerns the handling of subpage folios — units of the page cache used when filesystem block size is smaller than the kernel page size — and specifically the lifecycle of the PAGECACHE_TAG_TOWRITE (TOWRITE) tag during writeback. When writeback begins on a folio, the kernel must ensure that resources and ordering semantics are preserved until the folio is actually clean; the fix for this CVE ensures the TOWRITE tag is kept until the folio is cleaned, preventing ordering breakage. The public disclosure for CVE-2025-39779 was published on September 11, 2025; downstream vendor advisories and distro patch notices began appearing through September and October 2025 as maintainers incorporated the upstream fix into their kernels. The vulnerability carries a CVSS v3.1 base score of 5.5 in several vendor advisories, reflecting a local attack vector with no confidentiality or integrity impact but a meaningful availability impact when exploited or triggered (kernel oops/panic). What the bug actually does (technical overview)
The TOWRITE tag and folio writeback
Linux uses a combination of per-page and per-folio tags to track page cache state during read/write and writeback operations. The PAGECACHE_TAG_TOWRITE marker indicates that a page (or subpage within a folio) is scheduled for writeback. In the affected code, the routine that starts folio writeback for subpage folios called a function (folio_start_writeback and — prematurely — cleared the TOWRITE tag even when some subpage blocks inside that folio remained dirty.This premature clearing breaks higher-level ordering semantics. For example, btrfs relies on btrfs_wait_ordered_extents and related mechanisms to ensure that ordered write batches are completed before an operation that depends on ordering (such as truncation or synchronous fsync behavior). If pages are incorrectly marked as not TOWRITE while still dirty, other processes may not wait for those writebacks, causing race conditions, assertion failures, or unexpected file-system state during size or metadata operations. Upstream maintainers fixed this by introducing a variant that keeps the TOWRITE tag until the folio is actually clean (btrfs_subpage_set_writeback_keepwrite and only clearing the tag via a later xas-based operation.
The practical impact
- The defect manifests in workloads that exercise zoned setups and subpage folios (cases where block-size vs page-size mismatch matters), and under specific ordering-sensitive operations; it is not a wide-open remote code-execution vulnerability. The reported impact is availability — kernel oops or panic and data write ordering failures — rather than confidentiality/integrity compromise in the common case.
- Exploitation requires local access (low privileges are sufficient in some vendor scoring) and the right workload; therefore, affected systems running Btrfs and subject to those workloads are the primary concern. Many mainstream desktop and server deployments do not use Btrfs by default, but Btrfs is common in several distributions and in certain cloud or specialized storage setups.
Is Azure Linux the only Microsoft product that includes this library?
Short answer: No — Azure Linux is not necessarily the only Microsoft product that can include the vulnerable Btrfs code. Multiple Microsoft-distributed or Microsoft-maintained kernels and images include the Btrfs filesystem code; whether any Microsoft product is affected in practice depends on the exact kernel configuration and version shipped by that product and whether Btrfs is built-in or available as a module and actually in use.Below are the key Microsoft touchpoints to consider:
- Azure Linux (Microsoft’s Azure-tailored Linux distro) — Microsoft explicitly mentions that the Azure Linux distro includes the open-source component in question and that Microsoft will publish CSAF/VEX data and update the CVE record if further product impact is identified. This is the clearest confirmed Microsoft product inclusion.
- Windows Subsystem for Linux (WSL2) — Microsoft-maintained Linux kernel — Microsoft publishes and ships a Linux kernel used by WSL2 (the WSL2-Linux-Kernel repository and official kernel releases). That kernel repository contains the upstream btrfs sources and, in practice, the WSL2 kernel configuration exposes a variety of filesystem drivers and modules; WSL2 kernels are updated via Microsoft Update and can be replaced by users with a custom kernel. If a WSL2 kernel build used by a particular Windows release contains an affected upstream commit — and if btrfs code is built into that kernel or provided as a module — that WSL instance could be exposed to the same defect, especially if Btrfs is used inside WSL. However, confirmation requires checking the exact WSL kernel release string and config against the upstream fix commit.
- Azure VM and image kernels (kernel-azure and distro kernels) — Azure runs many Linux distributions on VMs. Those images often use vendor-supplied kernels (Ubuntu, SUSE, Oracle, etc.. Microsoft sometimes provides Azure-specific kernel builds (e.g., kernel-azure packages) or collaborates with distro maintainers to produce cloud-optimized kernels. Those kernel-azure builds may include btrfs sources and were explicitly mentioned as the target of fixes in vendor advisories; multiple vendors published security advisories for CVE-2025-39779 against their Azure kernels. In other words, an Azure VM running Ubuntu kernel-azure or SUSE kernel-azure could be affected until patched by the image/OS vendor or by applying the OS kernel update.
- Other Microsoft services (AKS, image build pipelines, marketplace images) — Microsoft’s managed services (for example Azure Kubernetes Service) run on node images that ultimately come from distribution vendors or Microsoft-curated images. If those node images use an affected kernel, the managed service nodes could be vulnerable until vendor patches are applied and node images updated. Microsoft’s initial advisory indicates it will update the CVE record if more Microsoft products are found to include the component; this implies the possibility that other Microsoft services or images could be impacted and will be disclosed if identified.
- Windows itself (native) — Windows (client/server) does not ship the Linux kernel or upstream Linux filesystem drivers as part of the base OS. Therefore, a typical Windows installation without WSL2 or WinBtrfs-style third-party drivers is not impacted by a Linux kernel Btrfs bug. That said, third-party projects providing a Btrfs driver for Windows exist; these are distinct codebases and would be affected only if they incorporate the same vulnerable upstream code. Evidence for such drivers (WinBtrfs) shows they are third-party and separate from Microsoft’s kernel builds.
What this means for Microsoft customers (practical guidance)
If you run infrastructure or endpoints in Microsoft ecosystems (Azure VMs, AKS, WSL2, Azure Linux images), treat the situation as one where several Microsoft-distributed kernels could include the vulnerable code. The presence of Btrfs code in a kernel does not automatically mean exposure — the real-world risk depends on:- Whether Btrfs is available in the kernel image (built-in or as a module).
- Whether Btrfs is actually mounted or in use on the system.
- The kernel version and whether it contains the upstream patch or vendor backport.
- The workload (zoned devices, subpage folios, truncation patterns) required to trigger the bug.
- Check whether you use Btrfs on any Microsoft-hosted systems:
- On Linux VMs and on WSL2 distributions, run: lsblk, mount, and cat /proc/filesystems to confirm whether btrfs is present or mounted.
- Check lsmod | grep btrfs or modinfo btrfs to see if the module is available.
- Check your kernel version and vendor advisory status:
- On Linux VMs: uname -sr and then consult your distro vendor security notices for CVE-2025-39779 or the kernel package changelog. Vendor advisories (Ubuntu, SUSE, Oracle, Amazon) started publishing patches in September–October 2025.
- On WSL2: run uname -r inside the WSL instance and compare against Microsoft’s WSL kernel release notes; update Windows and WSL via Microsoft Update if Microsoft has released a fixed WSL kernel. WSL’s kernel release tags and repo show which kernel versions Microsoft ships.
- Apply vendor or Microsoft-supplied kernel updates:
- For Azure Linux, follow Microsoft’s guidance and apply the Azure Linux distro updates when they appear; Microsoft committed to publishing CSAF/VEX notices to make the impact and mitigation precise.
- For Azure VMs running distro kernels, apply the kernel updates from the distribution (Ubuntu, SUSE, Oracle, Amazon Linux) or redeploy updated images as vendor advisories are released.
- If immediate patching is not possible, consider containment:
- Avoid using Btrfs-backed storage for critical workloads on affected systems until patched.
- For multi-tenant services, schedule rolling reboots and node replacements after kernel patching (AKS/VMSS node pool replacement).
- Where possible, remove the btrfs module or ensure it’s not loaded on systems that do not require it (modprobe -r btrfs), understanding that some kernels may have it built-in and not removable.
- Monitor Microsoft and vendor advisories:
- Microsoft’s security guidance indicated they will update the CVE if additional products are impacted and publish CSAF/VEX notices starting October 2025 to provide machine-readable impact statements; watch MSRC for updates.
How to check whether a Microsoft product you use is affected (concrete commands)
- Detect Btrfs usage and module presence:
- cat /proc/filesystems | grep btrfs
- mount | grep btrfs
- lsmod | grep btrfs
- modinfo btrfs
- Identify the kernel and vendor package:
- uname -a
- dpkg -l | grep linux-image (Debian/Ubuntu)
- rpm -qa | grep kernel (RHEL/SUSE/Oracle)
- For WSL2: inside the distro, uname -r will show the WSL2 kernel string (e.g., 6.6.x-microsoft-standard-WSL2); compare this to Microsoft release notes and to the upstream commit that fixes CVE-2025-39779.
- Confirm whether the specific upstream fix is present:
- Examine the vendor kernel changelog or kernel commit list (where published) for entries that mention btrfs_subpage_set_writeback_keepwrite, or the git commits referenced in public CVE listings. If you maintain your own kernels (e.g., WSL custom kernels), compare your kernel source tree to the upstream commit IDs that were used to close the CVE.
Risk and remediation timeline — a pragmatic assessment
- Severity: medium (CVSS 5.5); the real-world risk is concentrated where Btrfs is used in the specific subpage/zoned configurations that trigger the assertion. Widespread remote exploitation is unlikely because the attack vector is local.
- Who needs to act urgently:
- Teams running Btrfs on Azure-hosted Linux VMs (including nodes in AKS clusters) should prioritize kernel updates from their distro or Microsoft-curated images.
- Enterprises that allow WSL2 use with Btrfs inside developer machines should check the WSL kernel version, especially in environments where local code or CI jobs may exercise Btrfs intensively.
- Operators of specialized zoned storage or experimental setups that use subpage folios need to test and patch quickly.
- Remediation window:
- Vendors and cloud OS maintainers moved fast: many distros began shipping fixes in late September and October 2025. Apply vendor patches or Microsoft updates as soon as the fixed kernel packages or images are available.
Strengths and weaknesses of Microsoft’s initial public stance
Strengths (what Microsoft is doing right)
- Transparency commitment: Microsoft’s statement that it will publish CSAF/VEX (machine-readable supply-chain advisories) is a positive move for clarity and automation in enterprise vulnerability management; CSAF/VEX can help defenders quickly determine product impact and whether mitigations apply. Microsoft began publishing CSAF/VEX in October 2025 as part of its transparency push.
- Explicit identification of Azure Linux: Microsoft named Azure Linux specifically, which gives customers a clear starting point for remediation and avoids leaving them guessing whether Microsoft-maintained images are affected.
Weaknesses and residual risks
- Non-specific reference to other products: Microsoft’s message commits to updating the CVE if impact on additional products is identified — but it does not (yet) confirm or deny whether other Microsoft-maintained kernels (notably WSL2) contain the vulnerable code. That leaves a gap where WSL2 and other Microsoft-distributed kernels could be affected but customers do not have explicit confirmation. Enterprises relying on Microsoft-managed kernels must take a conservative posture and check versions.
- Operational ambiguity for cloud consumers: Azure runs many images and vendors’ kernels. Microsoft’s assurance about Azure Linux is helpful but not sufficient for customers running other official distro images or third-party marketplace images, where the responsibility for kernel updates may fall to the OS vendor or to the customer’s image lifecycle. Clearer guidance per image and per managed service (AKS node images, managed VM scale sets) would reduce management overhead for defenders.
Final recommendations (action checklist)
- Inventory:
- Identify any Azure VMs, AKS nodes, or WSL2 environments where Btrfs is present or where kernel-azure / Microsoft kernels are used.
- Verify:
- For each system, run uname -r and check the kernel package changelog or vendor security advisory for CVE-2025-39779 fixes.
- Patch:
- Apply vendor or Microsoft kernel updates as soon as fixed packages or kernel images are available. For managed services, plan node replacements after images are patched.
- Mitigate:
- If immediate patching isn’t possible, avoid using Btrfs volumes for critical workloads, unload the btrfs module where feasible, and restrict local access to machines that could trigger the condition.
- Monitor:
- Watch MSRC and your distro vendors for updated CSAF/VEX and advisories; Microsoft has stated it will update the CVE if additional products are affected, so re-check the MSRC advisory for changes.
Conclusion
CVE-2025-39779 is a targeted Linux kernel Btrfs bug that threatens write-ordering guarantees and can cause kernel assertions and availability failures under specific workloads; vendors and cloud providers began shipping patches in September–October 2025. Microsoft’s confirmation that Azure Linux includes the affected open-source component is an important, explicit acknowledgement, but it is not a blanket assurance that only Azure Linux is implicated. Microsoft-maintained kernels — notably the WSL2 kernel and Azure-specific kernel builds used in cloud images — include Btrfs code and therefore could be affected depending on the exact kernel configuration and version. Customers should assume a conservative posture: inventory Btrfs usage in any Microsoft-hosted or Microsoft-shipped kernels, confirm kernel versions against vendor patch lists, apply fixes promptly, and monitor vendor and MSRC advisories (including the promised CSAF/VEX updates) for any expansion of the product impact list. Caveat: whether a specific Microsoft product or image is affected requires checking the exact kernel release and configuration (whether Btrfs is built-in or provided as a loadable module) against the upstream fix — that verification is environment-specific and should be performed by operators using the commands and processes above.Source: MSRC Security Update Guide - Microsoft Security Response Center
