On November 12, 2025, Microsoft published a security advisory for a memory-safety flaw in the Linux kernel’s Btrfs file system that affects both Azure Linux virtual machines and Windows Subsystem for Linux 2 (WSL2). The bug, designated CVE-2025-40205, allows an out-of-bounds write of 8 bytes past a buffer during the creation of file handles — a mistake that can crash the kernel or, in some chained exploitation scenarios, escalate privileges. A fix has already been merged into upstream kernel trees, and major Linux distributors are shipping patched kernels.

The Bug: An 8-Byte Out-of-Bounds Write in Btrfs

At the center of CVE-2025-40205 is a simple programming error inside btrfs_encode_fh, the kernel function that builds file handles (unique identifiers) for files on a Btrfs volume. These handles are used for operations like exporting a Btrfs subvolume via NFS or for certain internal lookups.

The function can produce three sizes of file handles:

  • 20 bytes — for a non-connectable inode.
  • 32 bytes — for a normal connectable inode.
  • 40 bytes — when the file has a parent that lives in a different Btrfs root than the file itself.

Here’s where the bug crept in: when the code encountered the third case (a file whose parent and inode root IDs differed), it correctly wrote the larger 40-byte structure — but it told the caller that the handle was only 32 bytes. If the caller had allocated or provided a buffer exactly as large as the advertised 32 bytes, the kernel wrote the extra 8 bytes past the end of that buffer, corrupting adjacent kernel memory.

The flaw was discovered through code review and reported through the normal vulnerability disclosure process. The upstream fix, already backported to multiple stable kernel branches, makes two small but crucial changes:

  1. It now returns the correct size (40 bytes) for the parent-root-mismatch case.
  2. Before writing, it validates that the supplied buffer length is at least as large as the size it intends to write.

These changes eliminate the mismatch and prevent any out-of-bounds access. The patch is deliberately minimal, reducing the risk of regressions and making it easy to backport.

Who Is Affected on Windows

If you’re a Windows user who runs WSL2, you have a Linux kernel under the hood — and that kernel includes Btrfs support. While WSL2’s default root file system is ext4, the Btrfs kernel module is present and loaded on demand. That means your WSL2 environment is potentially vulnerable, but real-world risk depends on how you use it.

  • Typical WSL2 users who only interact with ext4 volumes (the default) are unlikely to trigger the bug unless they explicitly mount a Btrfs-formatted disk or image. The attack surface is limited.
  • Developers, testers, or hobbyists who mount Btrfs drives (for example, to work with images from a NAS or to test Btrfs features) are directly exposed. If you ever run a command like mount -t btrfs /dev/sdX /mnt or attach a Btrfs image via loop device inside WSL2, you should patch immediately.
  • Azure Linux virtual machines are also in scope. Microsoft’s own advisory confirms that Azure Linux images contain the vulnerable Btrfs code. If your Azure VM uses Btrfs as a root file system or for data volumes, you are at risk.
  • Windows native hosts are not affected — the bug lives purely in the Linux kernel. However, if you’re running WSL2 on a multi-user Windows machine, any local Linux user inside the WSL2 environment could potentially trigger the vulnerability.

Microsoft’s advisory currently covers Azure Linux and states that it will update its CSaF/VEX attestation records if other Microsoft-supplied kernels (such as those in Windows IoT or certain embedded products) are found to contain the vulnerable code. For now, you should verify your own WSL2 kernel version and treat it as potentially affected until proven otherwise.

How to Protect Yourself Now

The only reliable fix is to run a patched kernel. Here’s what you need to do depending on your environment.

WSL2 Users on Windows 10/11

  1. Check your WSL2 kernel version. Open a WSL2 terminal and run:
    bash uname -r
    Write down the kernel version string.

  2. Update WSL2. The easiest path is to run the following from a Windows PowerShell or Command Prompt:
    powershell wsl --update
    This will fetch the latest WSL2 kernel from Microsoft. After the update, restart WSL2 with wsl --shutdown and verify the kernel version again.

  3. Confirm the patch. As of mid-November 2025, the patched kernels are being distributed. The exact version numbers vary, but any kernel built from upstream stable tree 6.1.117 or newer, or 6.6.58 or newer (among others) should include the fix. Check the WSL kernel release notes or changelog for mention of CVE-2025-40205 or the commits btrfs: fix oob write in btrfs_encode_fh / btrfs: return correct handle size in btrfs_encode_fh.

  4. If you cannot update immediately, avoid mounting any untrusted Btrfs images inside WSL2. You can also unload the Btrfs kernel module if it’s not needed:
    bash sudo modprobe -r btrfs
    (This works only if no Btrfs volume is currently mounted.)

Azure Linux VM Administrators

  1. Review Microsoft’s CSAF/VEX advisory for CVE-2025-40205 to determine which Azure Linux images are affected and fixed.
  2. Identify vulnerable VMs. Run the following on each VM:
    bash uname -r cat /proc/filesystems | grep btrfs
  3. Apply the update. Update your VM to a patched image following Azure’s standard OS patching procedures. For Azure Kubernetes Service (AKS) nodes or VM scale sets, perform a rolling upgrade to replace nodes with newer, patched images.
  4. Reboot — kernel updates take effect only after a reboot.

Detection and Validation

After updating, monitor your system logs for Btrfs-related oops messages or stack traces. On WSL2, you can check the kernel log with dmesg; on Azure VMs, use journalctl -k. While the absence of crashes doesn’t prove the bug is fixed, a clean log after patching plus confirmation that your kernel version matches one of the known-good builds provides high confidence.

The Road to the Fix

CVE-2025-40205 is a textbook example of a “lost fix.” According to kernel maintainers, a previous attempt to correct the size mismatch had been made but was inadvertently dropped during code refactoring. The vulnerability lay dormant in the mainline kernel for several releases until it was re-discovered and patched for good in November 2025.

The disclosure timeline was short:
- Early November 2025 — The bug was identified and reported.
- November 12, 2025 — The CVE was reserved and public advisories started appearing in the National Vulnerability Database (NVD) and major distribution trackers (Ubuntu, Debian, SUSE, AWS).
- Mid-November 2025 — Upstream fixes were merged into Linus Torvalds’ tree and then into stable kernel trees (6.1.y, 6.6.y, 6.11.y, and others). Microsoft published its advisory for Azure Linux on the same day.
- Late November 2025 — Distributors began shipping patched kernel packages.

This is a local vulnerability; an attacker needs the ability to mount a crafted Btrfs image or trigger the file-handle encoding through specific sequences of operations. While no public exploit demonstrating reliable privilege escalation or remote code execution has surfaced, the memory corruption primitive is severe enough that security researchers rate its base CVSS score at 5.5 (medium severity) with an emphasis on availability impacts (kernel panic / denial of service).

What to Watch Next

Microsoft has promised to update its CSaF/VEX records if further investigation reveals that other Microsoft-provided kernels (such as those shipped with Windows IoT, some embedded SKUs, or older WSL2 distributions) also contain the vulnerable code. Administrators should subscribe to the Microsoft Security Response Center advisory for CVE-2025-40205 to receive notifications.

On the Linux side, downstream distributions will continue to backport the fix into their long-term support kernels. If you manage a fleet of Linux servers — whether on-premises, in Azure, or in any other cloud — ensure your patch management process picks up the relevant kernel updates in the coming weeks.

For Windows users, the key takeaway is straightforward: update WSL2, or temporarily disable Btrfs mounting if you can’t. The fix is already here; it’s just a matter of deploying it.