CVE-2025-38615 ntfs3 fix: Azure Linux is the only affected Microsoft product (so far)

A high‑impact Linux kernel patch landed in mid‑2025 closing a correctness flaw inside the ntfs3 in‑kernel NTFS driver; the vulnerability tracked as CVE‑2025‑38615 arises from a race condition that can mark a live inode “bad” during rename operations, and Microsoft’s advisory currently identifies its Azure Linux distribution as the only Microsoft product known to ship the vulnerable code — with the vendor promising to update that mapping if additional Microsoft products are found to include the same component.

Background / Overview​

ntfs3 is the modern, in‑kernel NTFS read/write driver that was upstreamed into the Linux kernel series (present across recent 5.x and 6.x kernels as a modulable filesystem: CONFIG_NTFS3_FS / module ntfs3). It was developed by Paragon and maintained as part of the mainline kernel; distributions enable or disable it at build time according to their packaging and support policies. The kernel’s official documentation describes ntfs3 as a full read/write implementation, supporting journalling, sparse and compressed files, and other NTFS semantics. CVE‑2025‑38615 is an upstream kernel issue in fs/ntfs3 described as “cancle set bad inode after removing name fails” (sic) in the commit/patch titles. The underlying problem is that under specific corrupted on‑disk conditions or interleavings, the kernel could call make_bad_inode on an inode that other code paths believe to be live and referenced; this can lead to inconsistent icache state and stability problems when the inode is concurrently referenced. The upstream patch was applied in the kernel trees (6.17+ series and backported into stable branches) to avoid calling make_bad_inode on inodes that remain attached/active, with the effect of removing the race and preventing live‑inode eviction during normal rename/remove operations. The public vulnerability records (NVD, distribution trackers and vendor advisories) classify the issue as a local, filesystem‑level correctness flaw that can cause availability or integrity impacts (kernel oops/panic or unexpected errors) when processing malformed NTFS metadata. The practical exploit model requires an attacker to present or cause the kernel to parse specially crafted NTFS structures — typically a local or image ingestion scenario rather than an unauthenticated remote network vector.

---

What Microsoft said (and what that means)​

Microsoft’s public advisory and communications around the CVE emphasize two points:

• Microsoft’s Azure Linux distribution (the Azure Linux kernels and images Microsoft builds and publishes for cloud workloads) does include the upstream kernel component that contains the ntfs3 code-paths in question. Microsoft has used its machine‑readable VEX/CSAF output to map third‑party CVEs against Azure Linux and to show which of its product builds ship the vulnerable kernel component.
• As of Microsoft’s advisory statement, Azure Linux is the only Microsoft product currently identified as including the ntfs3 component and therefore the only Microsoft product Microsoft is tracking as potentially affected. Microsoft commits to updating the CVE/VEX documents if additional Microsoft products are later found to include the same open‑source library. That explicit policy — publish VEX attestations for current scope and update when scope changes — is the vendor’s chosen transparency model.

Those two sentences are the crux: Microsoft has mapped the vulnerable kernel component to its Azure Linux product tree and is saying “we will update if we find more.” That is a valid and relatively standard approach for vendors that ship large amounts of third‑party open‑source code: identify affected product(s) now, and expand the product mapping if/when more internal SKUs are found to include the component.

---

Is Azure Linux the only Microsoft product that includes ntfs3?​

Short answer: Not necessarily by technical impossibility, but yes — Azure Linux is the only Microsoft product Microsoft has publicly identified as including ntfs3 at this time. Microsoft’s VEX/CSAF attestations and the MSRC product mappings list the Azure Linux kernel builds (the “azl3” kernel artifacts) as the components that contain the vulnerable ntfs3 code. Independent public trackers and distribution advisories corroborate that the affected code is the upstream ntfs3 module in specific kernel versions; Microsoft’s own machine‑readable product mapping identifies Azure Linux kernels as a known affected product. A deeper explanation and caveats follow:

Why Azure Linux is explicitly mapped​

• Microsoft builds and publishes a distinct Azure Linux kernel artifact and an Azure Linux distribution (sometimes referred to in vendor metadata as Azure Linux / azl3). When a third‑party CVE hits an upstream kernel component, Microsoft’s product telemetry and build manifests let vendor engineers determine whether that upstream component is present in a given Microsoft kernel build. For CVEs in ntfs3, Microsoft’s VEX documents identify the Azure Linux kernel versions that ship the vulnerable file system code.

Why other Microsoft products could include ntfs3 (but aren’t currently mapped)​

• Microsoft ships or maintains several other products that incorporate or build Linux kernels in‑house (examples include CBL‑Mariner kernels used historically in some Azure and edge services, certain Azure Marketplace images, and the Windows Subsystem for Linux (WSL) kernel distribution that Microsoft publishes). A kernel component like ntfs3 is upstream in the Linux kernel; whether a given Microsoft product includes it depends on how that product’s kernel was configured at build time (CONFIG_NTFS3_FS=y or =m) and whether Microsoft’s kernel packaging included the ntfs3 module in the published image. Public evidence indicates Microsoft’s tracking system is granular enough to show Azure Linux kernels as affected while other Microsoft kernel‑based products may have different configurations.

Evidence that other Microsoft Linux kernels may omit ntfs3​

• A publicly posted example of a WSL kernel configuration (representative of WSL2 kernel builds used by many Windows installs) shows # CONFIG_NTFS3_FS is not set, i.e., that particular WSL kernel build did not enable the ntfs3 module. That demonstrates that some Microsoft‑built kernels can be compiled without ntfs3 enabled; this explains why Microsoft might not map WSL to this CVE if their WSL kernels do not include the module. However, WSL is a product family with different kernel versions across time; a single config snippet does not prove absence across all WSL builds — it only shows a plausible reason why Microsoft’s initial mapping could list Azure Linux and not WSL.

Distribution and package evidence​

• Public vulnerability trackers and vendor‑side VEX/CSAF entries show multiple upstream distributions and vendors mapping the ntfs3 CVEs to their kernel packages (Debian, Ubuntu, SUSE, etc., and Microsoft’s CSAF/VEX outputs mirror that same approach for Azure Linux. That independent corroboration — upstream kernel commit, multiple distro advisories, and Microsoft’s VEX mapping — supports the claim that Azure Linux is the Microsoft product identified so far.

---

Practical verification — how operators should confirm whether a Microsoft product or host is affected​

Because whether a particular machine is vulnerable depends on the actual kernel build and whether the ntfs3 module is present and enabled, operators should verify directly on hosts and in vendor images.
Recommended checks (quick, reliable):

• Check for the module in a running kernel:
• Run: sudo modinfo ntfs3
• If modinfo returns metadata for ntfs3.ko, the module exists in the running kernel’s module tree.
• Check whether the module is loaded:
• Run: lsmod | grep ntfs3
• If present, the module is active.
• Check compiled kernel config for CONFIG_NTFS3_FS:
• Run: zgrep CONFIG_NTFS3_FS /proc/config.gz (or check /boot/config-$(uname -r).
• Example: if the line shows CONFIG_NTFS3_FS=m or =y, the kernel includes ntfs3 as a module or built‑in.
• Inspect the kernel package in offline images:
• For RPM‑based images: rpm -qpl kernel‑<version> | grep ntfs3
• For Debian/Ubuntu kernels: dpkg -L linux-image-<version> | grep ntfs3
• For cloud images:
• If you use Azure Linux images, consult Microsoft’s VEX/CSAF attestation (Microsoft publishes product‑level JSON VEX files for Azure Linux) and the kernel release notes that accompany Azure Linux updates to confirm product mapping and remedial guidance. Microsoft has explicitly published the VEX program and VEX artifacts for Azure Linux to provide that transparency.

If the module is present in your kernel build, treat the host as within scope for the vulnerability and follow the remediation steps below.

---

Remediation & mitigations​

The upstream kernel patch was merged; distributions (and Microsoft’s Azure Linux) are expected to ship patched kernels or backports. Operators should follow a standard patch-and-validate workflow:

• Locate vendor mapping and updated packages
• Confirm which vendor/kernel package contains the fix by consulting your distribution security tracker, the NVD entry for CVE‑2025‑38615, and — for Azure Linux — Microsoft’s VEX/CSAF artifact for the CVE. Microsoft has pledged to update its CVE mapping if other Microsoft products are identified later.
• Apply vendor kernel updates
• Install the patched kernel package from your distribution or vendor (for Azure Linux, apply Microsoft’s published kernel update for the affected azl3 kernel versions).
• Reboot hosts into the new kernel.
• Short‑term mitigations if immediate patching is impossible
• Blacklist ntfs3 module to prevent it from being loaded: add “blacklist ntfs3” to /etc/modprobe.d/blacklist.conf and rebuild initramfs if necessary. This prevents mounts via ntfs3 but does not remove the code from the kernel if it’s built‑in.
• Restrict mount and image ingestion: prevent untrusted users or automation from mounting NTFS images or mounting untrusted external media on affected hosts.
• Isolate and monitor: isolate image‑processing systems and CI/CD runners that may automatically mount or inspect guest images, and add filesystem‑related kernel oops monitoring to detect NTFS‑related oops/panics.
• Validate and document
• After patching and reboot, confirm: uname -r shows updated kernel, kernel changelog references CVE‑2025‑38615 or the upstream commit ID, and kernel logs no longer show the problematic oops signatures.
• For Azure customers using managed images or services
• If you rely on Azure Marketplace images, AKS node images or other Azure managed services that reference Azure Linux artifacts, follow the provider’s update guidance; Microsoft’s VEX/CSAF outputs and Azure update documentation are where Microsoft will publish remediation instructions and affected build mappings.

---

Risk analysis: exploitability, impact, and priorities​

• Exploitability: The fault is a local filesystem/kernel race/correctness bug that depends on either malformed on‑disk NTFS metadata or specific concurrent interleavings. Public trackers classify the practical risk as moderate with the most likely operational impact being kernel instability (oops/panic) or local denial‑of‑service; typical exploitability via remote network access is unlikely without additional vulnerabilities. That characterization is consistent across NVD, SUSE, Debian/Ubuntu advisories and upstream kernel discussions.
• Impact: For hosts that process third‑party NTFS images (virtualization hosts, image scanners, CI runners, backup appliances or systems that auto‑mount external media), the attack path is realistic and the operational impact can be high because a single crafted image can cause kernel crashes or data integrity issues on the host.
• Prioritization guidance:
• High priority: virtualization hosts and multi‑tenant image pipelines that might process untrusted NTFS images.
• Medium priority: desktops and single‑tenant hosts that might mount external NTFS media.
• Lower priority: hardened, air‑gapped systems that do not mount untrusted NTFS images and do not run third‑party image processing tools.

---

Why vendor‑level mapping matters (supply‑chain and VEX)​

Microsoft’s decision to publish VEX/CSAF attestations for Azure Linux — and to state explicitly which Microsoft SKUs include third‑party components — materially reduces the uncertainty for customers who operate mixed fleets. VEX attestation lets customers quickly determine whether a CVE that impacts an upstream component is relevant to a specific Microsoft product or image, avoiding noisy, erroneous triage and speeding prioritization. Microsoft published an MSRC blog about adopting VEX for Azure Linux in October 2025 as part of a broader transparency program. That program is precisely why Microsoft can say "Azure Linux is the known affected product" and why it will update push notifications if other Microsoft products are discovered to include the component. From a defensive standpoint, vendors publishing VEX/CSAF reduces false positives in enterprise vulnerability management systems and lets operators focus scarce remediation effort on the real blast radius. From a risk‑management standpoint, customers should still run host‑level verification (see checks above) because vendor attestations map products at build‑time; bespoke images, custom kernel builds, or third‑party marketplace artifacts may differ.

---

Cross‑checks and independent corroboration​

Multiple independent sources confirm the core facts:

• Upstream kernel commit and Linux filesystem mailing lists explain the bug title and the exact change (the commit/patch text appears with the message matching “cancle set bad inode after removing name fails”). That shows the root cause and the specific corrective change made in the kernel trees.
• Distribution advisories (Debian, Ubuntu, SUSE) and open vulnerability databases (NVD, OSV, Debian security tracker) list CVE‑2025‑38615 and describe the vulnerability as an ntfs3 kernel issue; multiple distro trackers list vulnerable and fixed kernel versions. This cross‑reference confirms the CVE scope at the distribution level.
• Microsoft’s VEX/CSAF artifacts and public messaging show that Azure Linux kernels are mapped in Microsoft’s internal product tree as shipping the affected kernel(s); Microsoft has published a blog post describing their VEX rollout for Azure Linux which frames how they will express “known affected / not affected / fixed” states for components like ntfs3. That confirms the vendor approach that produced Microsoft’s statement that Azure Linux is the only Microsoft product currently identified as shipping this component.
• A representative WSL kernel configuration from community sources shows ntfs3 not enabled in that particular WSL build, illustrating why not all Microsoft kernel products necessarily ship ntfs3 by default. This supports the vendor mapping (Azure Linux affected; WSL not mapped) but does not eliminate the need for per‑build verification.

---

Notable strengths and remaining risks​

Strengths in the response:

• The upstream community produced a small, surgical fix that upstream kernel maintainers merged into stable trees; that minimizes regression risk and makes vendor backporting practical.
• Microsoft’s VEX/CSAF program (and related public statements) provides a machine‑readable, vendor‑backed mapping between CVEs and specific Azure Linux kernel builds, making impact assessments faster for customers.

Residual risks and cautionary notes:

• Vendor attestations are only as good as the vendor’s product cataloging; custom images, self‑built kernels, or Marketplace images derived from vendor builds can differ and must be verified at the host level.
• The CVE class (filesystem parsing/correctness) can sometimes be chained with other bugs; an initially local, non‑exploit CVE can evolve into something more serious if combined with other bugs. Public trackers currently show no widely published remote exploit for CVE‑2025‑38615, but defenders should assume that proof‑of‑concepts can be developed over time and act accordingly.

---

Action checklist for WindowsForum readers responsible for mixed fleets​

• Inventory: Map all hosts and images that run Linux kernels (VMs, host OSes, WSL instances, container nodes, appliance images). Query running kernels for CONFIG_NTFS3_FS and check for presence of ntfs3. (Use the commands in the “Practical verification” section.
• Azure customers: Check Microsoft’s VEX/CSAF outputs for the CVE and the Azure Linux kernel release notes; apply the vendor‑published Azure Linux kernel updates when available.
• If you cannot patch immediately: blacklist the ntfs3 module, restrict mounting of untrusted NTFS images or external media, and isolate image ingestion pipelines.
• Test and validate: Apply patches in controlled test rings, reboot to ensure the fixed kernel is active, and check kernel logs for residual oops traces.
• Monitor: Add detection for ntfs3‑related kernel oops signatures, and watch Microsoft’s MSRC/CVE pages and VEX/CSAF artifacts for updates mapping additional Microsoft products into scope.

---

Conclusion​

CVE‑2025‑38615 is an upstream Linux kernel correctness bug in the ntfs3 driver that was fixed upstream and has been tracked by multiple distributions. Microsoft has identified Azure Linux as the Microsoft product currently known to ship the vulnerable ntfs3 code and has published machine‑readable attestations (VEX/CSAF) as part of its transparency program; Microsoft will update the CVE/product mapping if other Microsoft products are discovered to include the same open‑source component. Operators must not rely solely on vendor attestations — they should verify kernel builds and module presence in their environments, prioritize patches for systems that mount or process untrusted NTFS images, and apply short‑term mitigations where immediate patching is not possible. The combination of upstream fixes, vendor VEX attestations, and host‑level verification gives defenders the tools needed to reduce exposure — provided those tools are used proactively.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center