The Linux kernel patch tracked as CVE-2025-40087 fixes an NFSD (NFS server) edge case — adding a missing proc_layoutcommit handler for the FlexFiles pNFS layout to avoid a crash when a pNFS client issues a LAYOUTCOMMIT for that layout — and Microsoft has publicly attested that Azure Linux includes the implicated open‑source component and is therefore “potentially affected,” but that attestation is product‑scoped and should not be read as proof that no other Microsoft product could include the same kernel code.
The bug and fix in brief
Operators should: (a) apply the vendor patches for Azure Linux immediately if they run those images, (b) inventory their estate for other Microsoft Linux artifacts and verify kernel versions and configs, and (c) ingest vendor VEX/CSAF feeds to automate future triage. This combined approach — follow Microsoft’s attestation where it exists and validate (don’t assume) elsewhere — closes the practical gaps that a phased attestation rollout necessarily leaves open.
Source: MSRC Security Update Guide - Microsoft Security Response Center
Background / Overview
The bug and fix in brief- The vulnerability is located in the Linux kernel’s NFS server code (nfsd), specifically in the handling of the FlexFiles pNFS layout type. The upstream fix defines a missing proc_layoutcommit function so that if a pNFS client sends a LAYOUTCOMMIT for a FlexFiles layout the kernel no longer crashes.
- Public trackers classify the issue as primarily an availability problem (kernel crash/oom/oops) rather than a confidentiality or integrity compromise; attack complexity is generally low on systems where the path exists but exploitation requires the specific pNFS operations. Several distributors and security databases list the CVE and map it to fixed kernel versions or backports.
- Systems that host NFS server code and accept pNFS operations — particularly where FlexFiles layouts are in use — can experience a server crash or kernel oops when a client issues the LAYOUTCOMMIT sequence the fix addresses. This can cause service disruption for file servers and multi‑tenant hosts. Public advisories from Debian, SUSE and cloud vendors show the fix was merged into stable kernel trees and then packaged into distribution kernel updates.
- Microsoft’s Security Response Center (MSRC) entry for CVE‑2025‑40087 includes the sentence the user quoted: that Azure Linux “includes this open‑source library and is therefore potentially affected.” Microsoft also noted it began publishing machine‑readable CSAF/VEX attestations and will update CVE mappings if additional Microsoft products are later identified to ship the same component. That is a deliberate, procedural statement about Microsoft’s product inventory work.
What Microsoft actually said — and what that wording means
Microsoft’s wording is an attestation, not an exclusivity statement- Microsoft’s phrasing is best read as a product‑level inventory attestation: the company inspected the Azure Linux product family, found the upstream kernel component in those builds, and therefore listed Azure Linux as “potentially affected.” This gives Azure Linux customers a deterministic signal to triage and patch.
- Critically, the attestation does not assert that Azure Linux is the only Microsoft product that can ever include the same open‑source code. Absence of similar attestations for other Microsoft products is not proof those products are free of the vulnerable component — it simply means Microsoft has not yet completed the product‑by‑product inventory and published a VEX/CSAF attestation for them.
- VEX/CSAF formats are designed to be machine‑readable and actionable for automated triage. Large vendors typically roll them out in phases, starting with a manageable product family and expanding coverage. Microsoft began with Azure Linux and committed to extend attestations as inventories complete. That means the Azure Linux line is authoritatively in scope, while other Microsoft artifacts remain “unknown until proven otherwise.”
Is Azure Linux the only Microsoft product that includes the library and is therefore potentially affected?
Short answer- No — not necessarily. Azure Linux is the only Microsoft product Microsoft has publicly attested to include the implicated kernel component for CVE‑2025‑40087 at the time of its advisory, but other Microsoft artifacts that ship a Linux kernel could also include the same code depending on kernel version and build configuration. Treat the Azure Linux attestation as authoritative for Azure Linux, and treat other Microsoft products as unattested / unknown until Microsoft publishes additional VEX/CSAF mappings or you verify locally.
- The reason Microsoft named Azure Linux is operational: they performed an inventory of that product family and found the kernel component. The phrase “includes the open‑source library and is therefore potentially affected” is therefore accurate for Azure Linux and actionable for customers running those images. Microsoft’s promise to update the CVE record if more products are found to ship the code is a procedural commitment, not a technical exclusion.
- The vulnerable code is part of the Linux kernel source tree. Any Microsoft product that:
- ships a Linux kernel binary, or
- distributes an image or appliance containing a Linux kernel build that predates (or lacks) the fix, or
- provides a managed runtime that relies on an underlying host kernel containing the code,
could be a carrier. Typical Microsoft artifacts in scope include: - Windows Subsystem for Linux (WSL / WSL2) — Microsoft publishes and ships a WSL kernel; if that kernel version and config include the NFSD/FlexFiles code in the vulnerable commit range then WSL instances can be affected.
- linux‑azure / Azure‑tuned kernels used by some VM SKUs and Marketplace images — these are distinct kernel artifacts that must be inventoried independently.
- CBL‑Mariner / Azure host images and container host images — these distributions and host kernels are Microsoft‑managed and have historically been the first to receive VEX attestations.
- Marketplace appliances, partner images, or other Microsoft‑shipped Linux artifacts — each image may use vendor kernels or Microsoft’s builds; the specific kernel binary and CONFIG options determine presence.
- Independent vulnerability trackers and distribution advisories (Debian, SUSE, Amazon ALAS, Aqua, OpenCVE) list CVE‑2025‑40087 and describe the fix and affected kernel package versions, confirming the technical description and the mitigation path: update the kernel to a patched package or apply the upstream stable backport. These independent records corroborate the Microsoft attestation for Azure Linux and the technical nature of the bug.
Technical verification (what was checked and how to check your systems)
What to verify on your own systems- Kernel version and vendor package: check uname -r and consult your distro’s security advisory to determine whether your kernel package is listed as vulnerable or fixed. Distribution trackers have enumerated fixed versions for multiple kernel streams.
- Kernel configuration: the presence of a code path in the kernel is a build‑time property (CONFIG_* flags). Two kernels built from the same upstream tree can differ in surface area. Inspect /boot/config-$(uname -r) or /proc/config.gz to see if nfsd and related FlexFiles options are enabled.
- Module presence at runtime: confirm whether nfsd is present or loaded (systemctl status nfs-server, lsmod | grep nfsd). If your host does not run nfsd or does not accept pNFS client operations, your exposure may be lower.
- Check kernel version:
- uname -a
- Check kernel config (if available):
- zcat /proc/config.gz | grep -i nfs
- grep -i nfs /boot/config-$(uname -r) || true
- Check whether nfs server is installed or running:
- systemctl status nfs-server
- lsmod | grep nfsd
- For containers or images: run a quick probe of the image:
- docker run --rm image:tag sh -c 'uname -r && grep -i nfs /boot/config-$(uname -r) || true'
Operational guidance: triage, mitigation and remediation
Immediate triage (0–48 hours)- If you run Microsoft‑maintained Azure Linux images identified by Microsoft’s VEX/CSAF output, treat those images as in‑scope and follow Microsoft’s remediation guidance to apply patched kernels or updated images. Microsoft’s attestation for Azure Linux is authoritative for that product family.
- For other systems (including other Microsoft artifacts like WSL, linux‑azure, or Marketplace images), do not assume safety. Run the artifact checks above to determine exposure, and if an image or host is found to contain the vulnerable code, schedule kernel updates and reboot windows as required.
- Reduce the attack surface by limiting which services can accept pNFS/remote LAYOUTCOMMIT operations, disable or restrict NFS where practical, and isolate untrusted workloads.
- Monitor kernel oops, dmesg, and system logs for crashes or suspicious nfsd traces. Automated host‑level monitoring for kernel oops events can detect incidents early.
- Ingest VEX/CSAF feeds: consume vendor‑published VEX/CSAF artifacts (Microsoft’s feed for Azure Linux and subsequent attestations) into your SBOM and patch orchestration tooling to automate detection and triage. Microsoft’s CSAF/VEX outputs are intended to be machine‑readable for exactly this purpose.
- Bake fixed kernels into your image pipelines: rebuild and republish any custom or curated images that were derived from vulnerable bases.
- Harden image provenance and signing to prevent redeploying older, vulnerable base kernels.
Who should be worried — a prioritized exposure model
High priority (patch now)- Microsoft customers running the specific Azure Linux images named in Microsoft’s VEX/CSAF mapping for this CVE. Microsoft has attested these artifacts as including the component and therefore potentially affected. Apply Microsoft’s patched kernel images for Azure Linux.
- Any host acting as an NFS server using pNFS with FlexFiles layouts that is reachable by untrusted clients or tenants. Public trackers flag the bug as an availability risk and recommend kernel updates.
- VMs in cloud images where the kernel is supplied by the VM image vendor (Azure Marketplace images, partner appliances). Confirm the kernel version and vendor patch state.
- WSL2 installations on Windows that use Microsoft’s shipped kernel — check the WSL kernel version and the upstream commit mapping if you rely on WSL for production or development work that interacts with NFS.
- Systems that do not run nfsd or do not accept pNFS/remote LAYOUTCOMMIT operations. If nfsd is not present or the kernel is built without the FlexFiles code path, direct exposure is unlikely, but verify to be sure.
Critical analysis — strengths, gaps and risks in Microsoft’s approach
Strengths- Transparency and machine‑readable attestations: Microsoft’s phased rollout of CSAF/VEX outputs — starting with Azure Linux — provides deterministic signals for customers running those artifacts, enabling automation of triage workflows. That is a real operational win for large cloud customers and managed fleets.
- Clear remediation path for attested artifacts: for Azure Linux customers the attestation converts uncertainty into a concrete patching action: apply Microsoft’s updated Azure Linux kernel packages or image updates.
- Phased rollout leaves temporary visibility gaps: because VEX/CSAF publishing is product‑by‑product, many Microsoft artifacts remain “unattested” for any given CVE until Microsoft completes the inventory. Absence of attestation is not evidence of safety. Operators must still verify artifact‑level exposures.
- Artifact heterogeneity increases operational burden: Microsoft ships multiple Linux‑based artifacts (Azure Linux, linux‑azure kernels, CBL‑Mariner images, WSL kernels, marketplace appliances), each built and configured differently. Each artifact must be inventoried and patched individually if affected. This creates real workload for large estates.
- A common misinterpretation is to assume that because Microsoft named Azure Linux, only Azure Linux is at risk. That reading is incorrect and dangerous: Microsoft explicitly framed the statement as an inventory result for Azure Linux and promised to update the CVE if additional internal products are found to ship the code. Until such VEX/CSAF updates appear, other Microsoft artifacts must be treated as unknown.
Recommended checklist for Windows and Azure administrators
- If you run Azure Linux images identified by Microsoft for CVE‑2025‑40087: schedule and apply the Microsoft‑published kernel updates immediately and rebuild any derived images.
- Inventory all Microsoft‑supplied Linux artifacts in your estate (WSL, linux‑azure images, Marketplace images, AKS node images, managed host images) and map them to vendor CVE/VEX outputs. Do not assume these are covered by the Azure Linux attestation.
- For each artifact, verify kernel version and config: uname -r; check /boot/config-$(uname -r) or /proc/config.gz for nfsd / pNFS options. If the kernel is vulnerable or supports the FlexFiles layout, apply the vendor fix.
- Ingest vendor VEX/CSAF feeds into your SBOM and orchestration tooling so future Microsoft attestations automatically flag affected artifacts. Microsoft’s machine‑readable outputs are intended for this use.
- Apply compensating controls while patching: restrict pNFS access, isolate untrusted clients, and monitor logs for kernel oops / nfsd traces.
Conclusion
CVE‑2025‑40087 is a kernel‑level NFSD bug affecting the FlexFiles pNFS layout that upstream kernel maintainers fixed by adding the missing proc_layoutcommit handler to prevent crashes on LAYOUTCOMMIT. Multiple independent trackers and distribution advisories corroborate the technical description and map fixed kernel package versions for affected distributions. Microsoft’s statement that “Azure Linux includes this open‑source library and is therefore potentially affected” is accurate and actionable for Azure Linux customers — it is a product‑scoped inventory attestation and part of Microsoft’s phased CSAF/VEX rollout. However, that wording should not be read as a guarantee that no other Microsoft product can include the same vulnerable kernel code. Any Microsoft artifact that ships or runs a Linux kernel built from the vulnerable upstream range — including WSL kernels, linux‑azure builds, CBL‑Mariner artifacts, and Marketplace images — could be affected until Microsoft publishes a VEX/CSAF attestation for that artifact or you verify the kernel version and configuration locally. Treat Azure Linux’s attestation as definitive for that product and treat all other Microsoft‑supplied Linux artifacts as unknown until proven otherwise.Operators should: (a) apply the vendor patches for Azure Linux immediately if they run those images, (b) inventory their estate for other Microsoft Linux artifacts and verify kernel versions and configs, and (c) ingest vendor VEX/CSAF feeds to automate future triage. This combined approach — follow Microsoft’s attestation where it exists and validate (don’t assume) elsewhere — closes the practical gaps that a phased attestation rollout necessarily leaves open.
Source: MSRC Security Update Guide - Microsoft Security Response Center
