The short answer is: no — Azure Linux is not necessarily the only Microsoft product that could include the vulnerable Linux kernel code, but it is the only Microsoft product Microsoft has publicly attested so far to include the upstream component for CVE‑2025‑40105. Microsoft’s MSRC entry and machine‑readable CSAF/VEX attestations currently list Azure Linux as the known carrier and promise to update the CVE record if additional Microsoft SKUs are found to ship the same open‑source code; however, the presence (or absence) of the vulnerable code in other Microsoft artifacts depends on which kernel binary and kernel configuration those artifacts ship, and that requires artifact‑level verification.
CVE‑2025‑40105 is an upstream Linux kernel fix described as: “vfs: Don't leak disconnected dentries on umount.” In plain terms, the bug involves the VFS (virtual file system) layer: under a particular sequence of operations (for example calls to open_by_handle_at, reconnection logic in exportfs_decode_fh_raw, and certain lookup failures), the kernel could end up leaving dentries in an inconsistent “disconnected” state. That inconsistency may prevent proper reclaim, cause leaked dentries to remain in memory, and—when umount occurs first—can produce “busy inodes after unmount” conditions and availability/stability issues. Multiple distribution trackers and vendors have recorded the issue and scored it as a medium‑severity kernel stability/availability problem (CVSS v3 ≈ 5.5 in common vendor advisories). Two important technical points to keep in mind:
Put bluntly: Microsoft’s statement is authoritative for Azure Linux and is intended to be machine‑consumable for automated triage, but it intentionally does not attempt to be an exhaustive scan of every Microsoft image, kernel binary, or marketplace appliance at the time of publication. Microsoft’s public posture is to start with Azure Linux and expand VEX/CSAF attestations to additional SKUs as inventory work completes. Treat the attestation as a positive confirmation for Azure Linux and as a starting point, not an endpoint, for your broader Microsoft artifact inventory exercise.
However, answering whether Azure Linux is the only Microsoft product that includes the library requires careful language: no, Azure Linux is not necessarily the only Microsoft product that could contain the vulnerable kernel code. Other Microsoft‑distributed kernels (most notably WSL2’s kernel builds), CBL‑Mariner‑based artifacts, Azure host kernels and Marketplace images are plausible carriers depending on kernel version and build configuration — and they must be verified on an artifact‑by‑artifact basis until Microsoft expands its VEX/CSAF coverage or until your own inventory proves otherwise.
Act now: patch Azure Linux hosts per Microsoft guidance, inventory and verify other Microsoft artifacts (WSL2, Marketplace images, CBL‑Mariner nodes), and integrate Microsoft’s CSAF/VEX signals into your automation so you get immediate notification if Microsoft updates the CVE product mapping. The attestation is a helpful, machine‑readable start — but operational security still requires per‑artifact verification and timely patching.
Conclusion
CVE‑2025‑40105 is a Linux kernel VFS defect that can cause leaked dentries and availability issues. Microsoft’s public statement correctly identifies Azure Linux as a Microsoft product that “includes this open‑source library and is therefore potentially affected,” and Microsoft has committed to publish CSAF/VEX attestations (a transparency improvement) and update the CVE mapping if more Microsoft products are found to include the component. Nevertheless, Azure Linux being attested does not prove that no other Microsoft product includes the vulnerable code. Administrators should treat Azure Linux as a confirmed in‑scope product, patch it immediately, and then inventory and verify other Microsoft artifacts (particularly WSL2, kernel images used by Azure hosts, and any Microsoft‑distributed appliances or images) to determine exposure and remediate accordingly.
Source: MSRC Security Update Guide - Microsoft Security Response Center
Background / Overview
CVE‑2025‑40105 is an upstream Linux kernel fix described as: “vfs: Don't leak disconnected dentries on umount.” In plain terms, the bug involves the VFS (virtual file system) layer: under a particular sequence of operations (for example calls to open_by_handle_at, reconnection logic in exportfs_decode_fh_raw, and certain lookup failures), the kernel could end up leaving dentries in an inconsistent “disconnected” state. That inconsistency may prevent proper reclaim, cause leaked dentries to remain in memory, and—when umount occurs first—can produce “busy inodes after unmount” conditions and availability/stability issues. Multiple distribution trackers and vendors have recorded the issue and scored it as a medium‑severity kernel stability/availability problem (CVSS v3 ≈ 5.5 in common vendor advisories). Two important technical points to keep in mind:- This is an upstream Linux kernel VFS correctness/lifecycle issue, not a userland library bug; any product that ships a Linux kernel binary built from an upstream commit range that predates the fix could potentially carry the defect if the affected subsystem is present in the build.
- Exposure is conditional: even if a kernel binary comes from a vulnerable upstream version, the attacked code path must be enabled in that build (built‑in or as a module) and the triggering operations must be possible in the runtime environment. Many vendors therefore report product‑level impact after artifact‑level inventory.
What Microsoft actually said (and why that wording matters)
Microsoft’s public Security Update Guide and associated MSRC/CVE entry state that Azure Linux “includes this open‑source library and is therefore potentially affected”, and they note Microsoft began publishing machine‑readable CSAF/VEX attestations starting in October 2025 as part of a phased transparency program. Microsoft also explicitly committed to updating the CVE product mapping if it identifies additional Microsoft products that ship the same open‑source component. That phrasing is an inventory attestation for the product family Microsoft has scanned — it does not mechanically prove absence of the component in other Microsoft artifacts.Put bluntly: Microsoft’s statement is authoritative for Azure Linux and is intended to be machine‑consumable for automated triage, but it intentionally does not attempt to be an exhaustive scan of every Microsoft image, kernel binary, or marketplace appliance at the time of publication. Microsoft’s public posture is to start with Azure Linux and expand VEX/CSAF attestations to additional SKUs as inventory work completes. Treat the attestation as a positive confirmation for Azure Linux and as a starting point, not an endpoint, for your broader Microsoft artifact inventory exercise.
Could other Microsoft products include the same vulnerable code?
Short answer: yes — it’s plausible that other Microsoft‑shipped artifacts include the same upstream kernel VFS code, and therefore could be affected if their kernel versions and build configurations meet the vulnerable criteria. Microsoft has explicitly identified only Azure Linux so far, but other Microsoft‑distributed kernels and images are plausible carriers:- Windows Subsystem for Linux (WSL2) — WSL2 runs a Microsoft‑packaged Linux kernel inside a lightweight VM; Microsoft publishes the WSL kernel source, release notes and the kernel configuration used for its builds. Because WSL2 uses a real Linux kernel, the same upstream VFS sources (and their fixes) are relevant; whether a shipped WSL kernel is vulnerable depends on the WSL kernel release and its build configuration. Many security‑focused analyses and community threads note WSL’s kernel repo and the fact that kernel configuration choices determine presence or absence of specific subsystems.
- CBL‑Mariner / Azure host/kernel artifacts — Microsoft maintains distros and curated kernel builds for some Azure images (CBL‑Mariner lineage and linux‑azure style builds). Those kernel artifacts may include upstream kernel subsystems depending on their configuration. Microsoft’s VEX rollout has begun by mapping Azure Linux artifacts; CBL‑Mariner and other Microsoft‑maintained image families are obvious next candidates for verification.
- Azure Marketplace / curated VM images and managed node images (AKS, etc. — Marketplace and partner images are assembled from kernel packages and vendor images. If Microsoft or a marketplace publisher provides kernel‑level images that include the vulnerable upstream commit and enable the affected subsystem, those images would be in scope until patched. Microsoft’s single‑product VEX publication does not automatically extend to every marketplace or partner image.
- Other Microsoft appliances, edge and IoT images — any Microsoft‑distributed appliance or firmware image that embeds a Linux kernel is subject to the same rules: version + configuration determine exposure. Absence of a published VEX for such a product is not proof of absence.
- Windows client/server (native) — Windows itself does not ship the Linux kernel in the base OS, so a plain Windows install without WSL2 is not affected by an upstream Linux VFS bug. WSL2 is the notable exception where Microsoft does ship a Linux kernel binary as part of Windows servicing.
Why the distinction “attested” ≠ “only” matters operationally
Vendors who ship many artifacts typically publish product‑level attestations in waves: they scan and attest one product family first (here, Azure Linux), publish machine‑readable VEX/CSAF output for those artifacts, and then expand the mapping as they inventory more SKUs. Microsoft has been explicit about this phased approach: the Azure Linux attestation is a deliberate first step and a commitment to expand coverage. That means:- For Azure Linux customers: Microsoft’s attestation is a direct, authoritative signal — prioritize patching those images per Microsoft guidance.
- For other Microsoft artifacts (WSL2, Marketplace images, CBL‑Mariner hosts): do not assume they are unaffected just because they aren’t listed yet; perform artifact‑level verification until Microsoft publishes additional VEX attestations or until your own inventory proves the component is absent.
How to verify whether a Microsoft artifact in your estate is affected
Verification is an artifact‑level job: you must determine (1) which kernel binary is running/installed, (2) whether that kernel was built from a vulnerable upstream range, and (3) whether the affected code path is built into the kernel (CONFIG options or module present). Use the following checks as a runbook.- Identify the kernel and product artifact
- On a running Linux host: uname -a
- On WSL2: open a distro (or run wsl -d <distro> -- uname -a) to get the kernel string; also check wsl --status to see whether you’re using Microsoft’s shipped kernel or a custom kernel.
- Confirm kernel build metadata and configuration
- If available on the host: zcat /proc/config.gz | egrep 'EXPORTFS|VFS|CONFIG*DENTRY' (or specific CONFIG** relevant to the affected subsystem)
- Alternatively check /boot/config-$(uname -r) if present.
- If the kernel was supplied as part of a packaged distro, inspect the package changelog for CVE mapping (apt changelog linux-image-$(uname -r) or rpm -q --changelog kernel).
- Check for relevant module or file presence
- lsmod | grep -i exportfs || ls /lib/modules/$(uname -r)/kernel/fs | grep -i export
- Search /lib/modules for the specific driver or subsystem mentioned in the upstream advisory if applicable.
- Map kernel version to upstream fixes
- Compare your kernel release string to vendor CVE advisories and upstream stable branch fix commits. Distribution trackers (Debian, SUSE, Amazon Linux advisories) list the kernel package versions that include the fix; cross‑reference your uname output with those vendor mappings.
- WSL‑specific checks
- Confirm whether you are using Microsoft’s WSL kernel or a custom kernel. If you use the Microsoft kernel, update WSL via the documented update path (wsl --update) or via Windows Update to get the latest WSL kernel binary. If you use a custom kernel, rebuild it with the upstream fix applied.
Practical mitigation and remediation priorities
- Immediate: If you run Azure Linux images, treat Microsoft’s attestation as authoritative and apply the Azure Linux kernel updates Microsoft publishes for this CVE as soon as they are available. Integrate Microsoft’s CSAF/VEX outputs into automation to detect “known affected” artifacts in your estate.
- WSL2: update the WSL kernel Microsoft ships (wsl --update) or, if you rely on a custom WSL kernel, rebuild it against a patched upstream release and configure WSL to use the patched kernel. Confirm WSL kernel version after update (uname -r inside the WSL distro).
- Other Azure VM images / Marketplace images: verify the guest OS vendor’s advisories (Ubuntu, Debian, SUSE, etc. and apply distribution kernel updates inside the VM. If you run Microsoft‑curated images or appliances, check Microsoft VEX/CSAF for updates and treat un‑attested Microsoft artifacts as “requires verification.”
- Compensating controls (short term): restrict/untrusted local user access, harden container runtimes, quarantine workloads that can exercise the affected VFS operations, and monitor kernel logs (dmesg) for signatures of the underlying issue (busy inodes after umount, dentry leak messages). These measures reduce exploitability while you patch.
- Long term: integrate vendor‑published CSAF/VEX attestations into your vulnerability management pipeline so that product‑level changes are automatically reflected in your triage and prioritization. Microsoft has explicitly begun publishing these attestations and will update CVE records when they discover additional product carriers.
Threat model and risk assessment
- Attack vector: local — the practical exploit model described by vendors requires local operations that exercise the VFS reconnection and open_by_handle_at paths or trigger the same inconsistent dentry scenarios. That means multi‑tenant hosts, shared build agents, CI/CD workers, container hosts and developer machines with untrusted users/processes are the highest priority.
- Impact: availability/stability — the issue can result in leaked kernel objects, “busy inodes” at unmount, kernel oopses or resource exhaustion; vendors classify this as an availability/DoS risk rather than immediate remote code execution in the general case. Multiple trackers report a medium severity (CVSS v3 ≈ 5.5) for typical deployment scenarios.
- Likelihood of Microsoft‑ecosystem exploit: moderate for unpatched multi‑tenant hosts where attackers have local access; lower for single‑tenant systems without untrusted local access. Because the vulnerability has been widely cataloged and fixes exist upstream, threat actors may probe for unpatched kernels in the wild — prioritize patching of shared hosts and Developer/CI fleets (including WSL fleets used in developer environments).
Recommended prioritized action list (practical)
- Patch Azure Linux images immediately per Microsoft guidance; integrate the Azure Linux CSAF/VEX attestation into your vulnerability automation.
- Inventory Microsoft‑supplied kernels in your estate: list WSL hosts, CBL‑Mariner hosts, Azure Marketplace images, AKS node images, and any appliance images. Treat un‑attested artifacts as needing verification.
- For WSL fleets: run wsl --update (or apply the Microsoft WSL servicing path) and verify uname -r inside each distribution; for custom kernels, rebuild with upstream fixes.
- If you cannot immediately patch: apply compensating controls (restrict local user access, isolate multi‑tenant workloads, blacklist modules if feasible) and monitor kernel logs for symptoms.
- Subscribe to Microsoft’s VEX/CSAF feed for the CVE to receive automated updates if Microsoft expands product coverage beyond Azure Linux.
Strengths in Microsoft’s response — and residual risks
Strengths- Microsoft’s move to publish CSAF/VEX attestations for Azure Linux is positive and practical — it creates an authoritative, machine‑readable signal that can be automated in enterprise triage systems. The commitment to expand attestations reduces ambiguity for customers who run Azure Linux images.
- Upstream kernel maintainers produced focused fixes that map cleanly into stable kernels, making vendor backports tractable; distribution vendors and cloud providers are already mapping fixes into kernel package updates. Multiple independent advisories corroborate the fix and distribution mappings.
- Microsoft’s published attestation is product‑scoped; it does not prove that every Microsoft artifact is free of the vulnerable code. Absent attestations for other SKUs (WSL, CBL‑Mariner images, Marketplace appliances) are not guarantees of safety — they are simply not yet published. This leaves a verification burden on customers running mixed Microsoft artifacts.
- The vulnerability class (kernel VFS / lifecycle) can sometimes be chained with other bugs; availability/DoS issues can escalate in complex environments, so defenders should patch promptly in multi‑tenant or developer‑heavy contexts.
Final verdict
Microsoft’s public advisory and VEX/CSAF attestation make Azure Linux the single Microsoft product that Microsoft has explicitly confirmed as including the upstream component relevant to CVE‑2025‑40105 at the time of publication. That is actionable and authoritative for Azure Linux customers and should be treated as a high-priority patch target.However, answering whether Azure Linux is the only Microsoft product that includes the library requires careful language: no, Azure Linux is not necessarily the only Microsoft product that could contain the vulnerable kernel code. Other Microsoft‑distributed kernels (most notably WSL2’s kernel builds), CBL‑Mariner‑based artifacts, Azure host kernels and Marketplace images are plausible carriers depending on kernel version and build configuration — and they must be verified on an artifact‑by‑artifact basis until Microsoft expands its VEX/CSAF coverage or until your own inventory proves otherwise.
Act now: patch Azure Linux hosts per Microsoft guidance, inventory and verify other Microsoft artifacts (WSL2, Marketplace images, CBL‑Mariner nodes), and integrate Microsoft’s CSAF/VEX signals into your automation so you get immediate notification if Microsoft updates the CVE product mapping. The attestation is a helpful, machine‑readable start — but operational security still requires per‑artifact verification and timely patching.
Conclusion
CVE‑2025‑40105 is a Linux kernel VFS defect that can cause leaked dentries and availability issues. Microsoft’s public statement correctly identifies Azure Linux as a Microsoft product that “includes this open‑source library and is therefore potentially affected,” and Microsoft has committed to publish CSAF/VEX attestations (a transparency improvement) and update the CVE mapping if more Microsoft products are found to include the component. Nevertheless, Azure Linux being attested does not prove that no other Microsoft product includes the vulnerable code. Administrators should treat Azure Linux as a confirmed in‑scope product, patch it immediately, and then inventory and verify other Microsoft artifacts (particularly WSL2, kernel images used by Azure hosts, and any Microsoft‑distributed appliances or images) to determine exposure and remediate accordingly.
Source: MSRC Security Update Guide - Microsoft Security Response Center
