Microsoft’s brief advisory that “Azure Linux includes this open‑source library and is therefore potentially affected” is accurate as a product‑level statement — but it is not a categorical proof that no other Microsoft product can include the same vulnerable kernel code.
Background / Overview
CVE‑2025‑39905 is an upstream Linux kernel fix described in the phylink subsystem: a synchronization change that adds a lock to serialize concurrent writes to pl->phydev when phylink_resolve races with bringup/disconnect paths. The patch resolves an inherent lock‑ordering/race condition and prevents future deadlocks or data races in PHY bring‑up/disconnect sequences. Upstream metadata and kernel stable commits summarize the change and provide the canonical technical description. Microsoft’s published advisory (MSRC Security Update Guide) states that
Azure Linux includes the implicated open‑source library and is therefore potentially affected and notes that Microsoft began publishing machine‑readable CSAF/VEX attestations in October 2025. That attestation is a machine‑readable, product‑scoped statement about the inventory Microsoft has completed so far. Microsoft also committed to update CVE/VEX records if additional Microsoft products are identified to ship the component. This distinction — between a product‑focused attestation and a universal exclusion — is the central point of the operational question: is Azure Linux the only Microsoft product that includes the vulnerable component? The short, precise answer is:
No — Azure Linux is the only Microsoft product Microsoft has publicly attested to include the component so far, but that does not prove other Microsoft products cannot include the same code.
What Microsoft’s wording actually means
Product attestation vs. ecosystem exclusion
- Product attestation (what Microsoft did): Microsoft inventory‑checked the Azure Linux distribution (CBL‑Mariner lineage) and published a CSAF/VEX attestation that maps the upstream component into that product family. That attestation is authoritative and actionable for operators running Azure Linux images.
- Ecosystem exclusion (what Microsoft did not do): The attestation is not a categorical statement that every Microsoft product or image is free of the component. Microsoft’s VEX rollout is phased — beginning with Azure Linux — and the company explicitly pledged to update attestations if subsequent inventory work finds the component in other products. Absence of an attestation for another Microsoft product is absence of mapping, not proof of absence of the vulnerable code.
Why vendors use this language
VEX/CSAF attestations are designed to be machine‑consumable and precise: a vendor declares the status for each product artifact (Not Affected / Under Investigation / Known Affected / Fixed). For large vendors with hundreds of SKUs and build artifacts, the pragmatic rollout is product‑by‑product. Microsoft’s October 2025 VEX rollout began with Azure Linux as the first product family to receive attestations; that phased approach explains why one product can be named while others remain un‑mapped for a time.
Technical context: why the attestation matters — and why it’s incomplete by design
Where the vulnerability lives
CVE‑2025‑39905 is a change in the Linux kernel’s networking/phylink area that eliminates a potential lock inversion by adding an extra lock to serialize updates to pl->phydev. The fix is small and localized in kernel source; its presence in any given binary depends purely on the kernel version and compile‑time configuration shipped in that product image. Upstream commit references and vendor trackers document the exact stable commits that carry the fix.
Why product scope matters
Large vendors ship many distinct kernel artifacts:
- Distribution images (Azure Linux / CBL‑Mariner lineage).
- Azure‑tuned kernel packages (linux‑azure / kernel‑azure) used in VMs and managed services.
- WSL2 kernel binaries distributed to Windows users.
- Microsoft‑curated Marketplace VM images and partner images.
- Container images and statically linked binaries that may embed kernel modules or userland libraries in different versions.
Each artifact is built independently; presence of a given upstream source line (or the fix) is per‑artifact. That’s why an attestation for Azure Linux is decisive for that product, but not determinative across the entire Microsoft footprint.
Cross‑checking the record: independent confirmation
Multiple independent trackers confirm the technical CVE description and upstream fixes for CVE‑2025‑39905. NVD lists the CVE and references the kernel stable commits; kernel.org provides the upstream commits themselves; vendor trackers (Tenable, SUSE, OpenCVE) mirror the same description and chronologies. Those independent sources corroborate the technical facts and the timeline of fixes. Microsoft’s own blog posts and MSRC guidance confirm the VEX/CSAF rollout timeline (October 2025) and the product‑by‑product inventory approach. That public admission explains the MSRC phrasing and affirms Microsoft will expand attestations over time.
Practical implications for customers and operators
Short takeaways (actionable)
- If you run Azure Linux images, treat Microsoft’s attestation as authoritative: those images include the implicated component and should be patched according to Microsoft’s guidance.
- If you run other Microsoft‑provided artifacts (WSL2, linux‑azure kernels, Azure Marketplace VMs, AKS node images, curated container images), do not assume they are unaffected. Inventory each artifact and verify kernel versions and SBOMs.
- If you manage on‑prem or partner‑provided appliances running in Azure or using Microsoft images, treat Marketplace and partner images as distinct vendors’ artifacts and validate them independently.
A prioritized runbook for verification and mitigation
- Patch Azure Linux images immediately if they are used in your estate. Apply Microsoft’s published updates and reboot nodes per vendor instructions.
- Inventory Microsoft artifacts in your environment:
- List VM images, kernels (uname -a), and container base images.
- Collect SBOMs or package manifests for images you do not build yourself.
- Identify WSL2 kernel versions on developer machines.
- Map kernel versions to upstream stable commit IDs that fix CVE‑2025‑39905. Confirm your vendor or package changelog references the upstream commit or CVE.
- For managed services (AKS, Azure VM scale sets), confirm whether the service uses vendor kernels or Microsoft‑supplied kernels; consult service documentation and Microsoft’s VEX/CSAF outputs when available.
- If immediate patching is impossible, restrict who can perform local operations that could trigger the phylink race and apply compensating controls (isolate/orchestrator segmentation, EDR process constraints).
- After patching, validate with targeted functional tests for network bring‑up/teardown operations and monitor kernel logs for WARN_ON or oops traces referencing phylink or PHY bring‑up code.
Useful detection and inventory commands
- Get running kernel info: uname -a
- Check kernel module list: lsmod | grep phylink
- Search dmesg/journal for phylink traces: journalctl -k | grep -i phylink
- Verify package changelog: rpm -q --changelog kernel-package | grep CVE-2025-39905 (or apt changelog equivalents)
- For WSL2, check the WSL kernel version shipped by Windows: wsl --status and uname output inside WSL.
Risks, strengths and practical analysis of Microsoft’s VEX approach
Notable strengths
- Improved automation and clarity: Publishing machine‑readable CSAF/VEX attestations reduces ambiguity for customers and security tooling, allowing rapid automated triage for product artifacts Microsoft has inventoried. This dramatically shortens detection-to-remediation cycles for those products.
- Authoritative signal for Azure Linux: Microsoft’s explicit attestation is a high‑quality, actionable signal for operators running Azure Linux images, enabling confident prioritization of patches.
- Phased, verifiable rollout: A product‑by‑product rollout is operationally sensible for a large vendor; it reduces errors in attestations and lets Microsoft validate with partners before expanding coverage.
Residual risks and limitations
- Incomplete coverage during the rollout window: Until Microsoft maps additional products, many Microsoft artifacts remain “unknown.” That unknown tail is a material risk because large organizations often run a blend of Microsoft‑supplied kernels and vendor kernels across cloud, edge, and developer machines. Absence of a VEX attestation is not a guarantee of safety.
- Marketplace and partner image long tail: Third‑party Marketplace images hosted on Azure may be built and patched on very different timelines; they are not automatically covered by Microsoft’s Azure Linux attestation. Customers must treat those images as separate entities.
- Static embedding and custom builds: Statically linked or embedded instances of libraries in appliances and containers may persist even after distribution packages are patched. Automated SBOM and binary scanning are required to find those cases.
Operational risk ranking (practical view)
- High priority: Azure Linux VMs and images flagged by Microsoft as Known Affected — patch immediately.
- Medium priority: Microsoft‑supplied kernel artifacts (linux‑azure packages, WSL2 kernels) — inventory and confirm patch status.
- Lower priority (but non‑trivial): Third‑party Marketplace images, partner appliances, and container images — treat as unknown until vendor confirmation or SBOM/scan.
Verification checklist for security teams
- Confirm whether the Microsoft product(s) you run are named in Microsoft’s CSAF/VEX outputs. If they are, follow Microsoft’s remediation timeline for that product.
- If a Microsoft product is not named, perform artifact‑level checks: kernel version, module presence, package changelog, and SBOM inspection.
- Use binary/package scanning tools to detect vulnerable upstream code presence in images and appliances (e.g., scanning for specific upstream function names, commit IDs or CVE tag mentions).
- Maintain centralized kernel logging and alerting for WARN_ON/OOPS traces that may indicate problems even after a patch is applied.
- Track Microsoft’s VEX feed and vendor advisories periodically; Microsoft has pledged to update CVE records when it identifies additional products that ship the component.
Flagging unverifiable claims
- Any statement that definitively claims a particular Microsoft product beyond Azure Linux either includes or excludes the affected phylink code should be treated as unverifiable unless Microsoft publishes a VEX attestation for that product or the product artifact is inspected directly. Microsoft’s public commitment to expand its attestations means definitive answers will come from either vendor attestations or artifact inspection. Until then, treat non‑attested products as unknown and verify them yourself.
Conclusion
Microsoft’s MSRC entry for CVE‑2025‑39905 is correct and useful:
Azure Linux includes the implicated open‑source component and is therefore potentially affected, and Microsoft’s move to publish machine‑readable CSAF/VEX attestations (started October 2025) gives Azure Linux customers an authoritative, automatable signal for triage. However, that attestation is
product‑scoped, not an ecosystem‑wide guarantee. Azure Linux is the only Microsoft product Microsoft has publicly attested to include the component so far, but other Microsoft artifacts — WSL2 kernels, linux‑azure packages, Azure Marketplace images, and partner appliances — can still carry the same vulnerable upstream code depending on their kernel versions and build configurations. Security teams must therefore combine Microsoft’s VEX/CSAF outputs with artifact‑level inventory, SBOM review, and binary/package scanning to gain complete assurance across their estates.
Immediate operational priorities remain clear: patch attested Azure Linux images now, inventory and verify all Microsoft‑provided artifacts you run, and rely on SBOMs and runtime telemetry to find any remaining long‑tail exposures. The vendor’s phased transparency program is a meaningful improvement — but it shifts the burden to operators to verify the un‑attested parts of their environments until Microsoft completes its broader inventory.
Source: MSRC
Security Update Guide - Microsoft Security Response Center