On [date, mid-2025], Microsoft dropped an advisory for CVE-2025-38615, a Linux kernel flaw lurking in the ntfs3 driver, and delivered a clear message: Azure Linux is the only Microsoft product currently known to ship the vulnerable code. A race condition during rename operations can corrupt the kernel's inode cache, potentially leading to crashes or system instability when handling malformed NTFS filesystems. The company promises to update its guidance if other products are later found to include the same component.

What changed under the hood

The bug sits inside the ntfs3 driver — a modern, in-kernel read/write NTFS implementation originally developed by Paragon Software and later mainlined. On affected kernels, a specific interleaving of rename and removal actions on a corrupted NTFS volume could trick the kernel into calling make_bad_inode on a live inode. Because that inode might still be referenced elsewhere, the result is an inconsistent state that can trigger kernel oops or panics.

Upstream maintainers merged a surgical fix (visible in kernel 6.17 and later, with backports flowing into stable trees) that stops the driver from marking an inode bad when a removal step fails. The patch prevents the race outright, so no special tuning is required once the fixed kernel is installed.

Microsoft's advisory — published through its Security Response Center and machine-readable VEX/CSAF artifacts — explicitly maps CVE-2025-38615 to Azure Linux kernel builds. The advisory states: "We will update the CVE if impact to additional products is identified." That language reflects the company's broader transparency model kicked off in October 2025, when it began using CSAF/VEX to link upstream CVEs to its own products.

What it means for you

The practical impact depends entirely on whether your Linux system includes the ntfs3 module and mounts — or could one day mount — an untrusted NTFS image.

For Azure Linux users: This is your bug. Microsoft has already published kernel updates for the affected azl3 images. If you run Azure Kubernetes Service nodes, Azure Marketplace appliances, or self-managed Azure Linux VMs, check the latest kernel release notes and apply the patched kernel. Microsoft's VEX documents will list the specific fixed image versions, and you can cross-reference them against your running kernel with uname -r.

For everyone else running Linux — including WSL and cloud VMs: Don't assume you're in the clear. Many organizations run custom images or containers derived from Azure Linux or other distributions that may enable ntfs3. Even the Windows Subsystem for Linux (WSL) isn't immune by default: earlier WSL kernel builds omitted ntfs3, but newer versions or custom configurations could have it enabled. The only reliable check is host-level verification.

Run these commands on any Linux machine you care about:

  • sudo modinfo ntfs3 — if it returns module metadata, the driver is present in the kernel tree.
  • lsmod | grep ntfs3 — if the module appears, it's actively loaded and ready to handle NTFS mounts.
  • zgrep CONFIG_NTFS3_FS /proc/config.gz (or check /boot/config-$(uname -r)) — a line showing =y or =m confirms the kernel was compiled with ntfs3 support.

If any of these turn up positive, treat the host as affected and prioritize remediation.

Risk levels by workload:

  • High: virtualization hosts, CI/CD runners that process container images or disk snapshots, backup appliances, and forensic workstations that might mount third-party NTFS volumes. A crafted image can crash the host and disrupt multi-tenant services.
  • Medium: developer laptops or single-user desktops that occasionally plug in external NTFS drives. The attack surface is smaller, but a drive-by USB scenario isn't far-fetched.
  • Low: air-gapped systems that never touch untrusted media, or hardened servers where the ntfs3 module is already blacklisted. Even so, verify — configuration drift happens.

How we got here

Ntfs3 entered the mainline kernel in the 5.15 series (late 2021) and quickly became the go-to driver for read/write NTFS on Linux, supplanting the older ntfs-3g FUSE implementation for many workloads. Because it's built-in, any distribution that turns on CONFIG_NTFS3_FS ships it by default. Microsoft itself adopted ntfs3 in Azure Linux to ensure compatibility with Windows-originated data in cloud environments.

Microsoft's decision to publicly map Azure Linux to CVE-2025-38615 flows from its 2025 transparency push. The CSAF/VEX program makes machine-readable attestations available so security teams can automatically filter out CVEs that don't apply to their specific Microsoft products. The advisory's careful language — "Azure Linux is the only Microsoft product identified as including this open-source library" — is both a statement of current knowledge and a promise of ongoing diligence.

The bug class is familiar in filesystems: a race between two operations that touch the same inode. Upstream discussion shows the fix was uncontroversial and targeted, which bodes well for stable backports.

What to do now

If ntfs3 is present on any of your systems, take these steps in order:

Patch if you can

  • Azure Linux: Pull the latest kernel from Microsoft's update channels. The advisory and associated VEX data will indicate which kernel version contains the fix. Reboot after installation.
  • Other distributions: Check your vendor's security tracker. Debian, Ubuntu, SUSE, Red Hat and others have already issued fixed kernel packages. Apply them through your normal update channels and reboot.

Mitigate if you can't patch immediately

  • Blacklist the module: Create /etc/modprobe.d/blacklist-ntfs3.conf containing blacklist ntfs3, then rebuild initramfs (update-initramfs -u or dracut --force). This prevents automatic loading, though it won't help if ntfs3 is compiled into the kernel (check with zgrep CONFIG_NTFS3_FS — if it shows =y, blacklisting isn't effective).
  • Restrict mounts: For systems that must keep the module, use udev rules or PolicyKit to block automounting of unknown devices. At minimum, tell users not to attach external NTFS drives to affected machines.
  • Isolate risky workloads: Move image-processing pipelines to dedicated hosts that either have patched kernels or don't mount NTFS filesystems at all.

Verify your patch

After rebooting into a new kernel:

  • uname -r should match the fixed version.
  • modinfo ntfs3 | grep version can reveal the driver version; check it against your vendor's advisory.
  • Watch kernel logs (dmesg -T | grep -i ntfs) for any oops or error traces during normal operation.

For managed cloud services

If you use Azure services that reference Azure Linux (AKS node images, Azure Functions containers, etc.), Microsoft will roll out updated images through its normal release channels. The VEX documents will serve as your formal signal that a fixed image is available. Until then, verify with the commands above and request updated images from your provider if the module is present.

What to watch next

Microsoft's advisory says it will update the CVE record if other products are found to include the vulnerable ntfs3 code. Given the prevalence of Linux subsystems across the Microsoft product line — from Azure Sphere to IoT Edge — it's plausible that additional kernels could surface. The VEX/CSAF infrastructure means those updates will be machine-readable and automatically feed into vulnerability scanners, but that only works if your team subscribes to the feed. In the short term, keep an eye on the MSRC advisory page for CVE-2025-38615 and your own host-level inventory. The fix itself is straightforward, and most major distributions have already shipped it. The remaining risk lies in the undiscovered corners of your fleet where ntfs3 is quietly enabled.