Microsoft has publicly confirmed that its Azure Linux distribution is potentially affected by a newly patched Linux kernel vulnerability that can cause system crashes on servers with high-end Mellanox networking gear. But the company’s advisory stops short of clearing other Microsoft-distributed Linux kernels, leaving administrators to manually hunt down the same flaw in everything from WSL2 instances to managed Kubernetes node images.
The vulnerability, assigned CVE-2025-38109, resides in the mlx5 driver’s handling of embedded chip virtual functions (ECVFs) during device shutdown. A use-after-free bug can trigger refcount underflows, leading to kernel panics and denial of service. Upstream fixes have been released, and major Linux distributions have already shipped patched kernels. For Azure Linux users, Microsoft’s advisory provides a clear signal to update. For everyone else running Microsoft-supplied Linux artifacts, the advisory is a starting point—not a safety guarantee.
What Actually Changed
Security researchers disclosed CVE-2025-38109, a flaw in the net/mlx5 driver that ships with the Linux kernel. The driver, which supports Mellanox (now NVIDIA) ConnectX and BlueField adapters, contains a logic error in the shutdown path when ECVF vports are present. When the system powers down or unloads the driver, the vport ACL ingress table can be destroyed incorrectly, leaving stale memory references. Subsequent attempts to free or access that memory trigger the use-after-free, with symptoms including refcount_t underflow warnings in kernel logs and full system oops (kernel crashes).
The fix, merged into the upstream Linux kernel, ensures that ECVF vports are unconditionally cleaned up during shutdown, correcting the reference counting. Because the bug only manifests on systems that actually use the mlx5 driver with ECVF features, not every Linux host is at risk—but the driver is commonly included in enterprise and cloud-distributed kernels.
Microsoft’s response came via its Security Response Center (MSRC) advisory. In a notable shift in transparency, the company not only published a textual confirmation that Azure Linux “includes this open-source library and is therefore potentially affected,” but also released machine-readable CSAF/VEX (Common Security Advisory Framework / Vulnerability Exploitability eXchange) attestations. These are designed to let organizations automate vulnerability tracking across their software inventory. Microsoft began this CSAF/VEX rollout for Azure Linux in October 2025, as reported in its own blog post.
Crucially, the advisory states, “If impact to additional products is identified, we will update the CVE to reflect this.” That means other Microsoft products—such as the linux-azure kernels used in some Azure VM SKUs, WSL2 kernels, Azure Kubernetes Service (AKS) node images, and curated Marketplace images—have not yet been attested as affected or not affected. They remain unverified.
What It Means for You
The practical impact depends on what you run.
Azure Linux Customers
If you use Azure Linux images (the lightweight, Microsoft-maintained distribution formerly known as CBL-Mariner), you have an explicit Microsoft confirmation: your systems are potentially affected by CVE-2025-38109. You should treat this as a high-priority patch, especially if your workloads run on or manage Mellanox hardware with SR-IOV or BlueField features. Apply the latest kernel packages from your distribution channel immediately; the fix is already integrated.
Operators of Other Microsoft-Distributed Linux Kernels
This group includes anyone using:
- WSL2 on Windows (the kernel is Microsoft-maintained)
- Linux virtual machines in Azure that run the linux-azure kernel flavor
- AKS node pools with Microsoft-provided images
- Azure Marketplace images from Microsoft that bundle a Linux kernel
For these, Microsoft’s advisory does not confirm or deny the presence of the vulnerable code. Your default assumption should be “unverified” rather than “safe.” Without a CSAF/VEX attestation or your own inspection, you cannot rule out that the mlx5 driver—and the vulnerable code path—was compiled into the kernel. Even if you aren’t actively using Mellanox hardware, the driver may still be loaded or present, potentially triggering during system shutdown or driver unload.
Home and Client Users
If you run Windows with WSL2 for development, risk is low in practice because WSL2’s virtualized network adapter does not typically expose Mellanox hardware to the Linux guest. However, WSL2 kernels are Microsoft-built and could theoretically contain the driver. The risk of a crash is minimal unless you explicitly pass through a high-performance NIC or a specific virtual function. Most home users can defer patching until they receive a standard update, but developers who run custom kernel modules or pass-through hardware should check.
Enterprise Linux Users Not on Microsoft Kernels
If you run standard distributions (Ubuntu, RHEL, SUSE) directly on your hardware or in the cloud, Microsoft’s advisory is irrelevant to you—but the vulnerability still applies. You need to check your distribution’s security feeds and apply kernel updates as usual. All major enterprise distros have published fixes.
How We Got Here: Microsoft’s Evolving Linux Vulnerability Disclosure
Historically, Microsoft’s handling of Linux kernel CVEs in its own products has been opaque. With the rise of Azure and the company’s deeper involvement in Linux (including maintaining its own distribution), the pressure for clear software supply chain security practices grew. In October 2025, Microsoft began publishing CSAF/VEX attestations for Azure Linux, aiming to provide machine-readable impact statements that integrate with enterprise vulnerability management tools.
The rollout is phased, starting with Azure Linux because it’s a well-bounded set of artifacts under Microsoft’s direct control. The company’s long-term goal is to extend these attestations to other Linux-based products, but today, only Azure Linux benefits. This mirrors challenges across the industry: complex software products often embed open-source components, and identifying exactly which components are in which builds is a non-trivial data problem.
The CVE-2025-38109 advisory is a telling example. The vulnerability is in an upstream driver that might be included in many kernels, but Microsoft’s attestation only covers the one distribution it has fully inventoried. This is not a failure of the advisory—it’s a reflection of the current state of inventory maturity. For operators, it means manual verification is still required outside the attested scope.
What to Do Now: A Practical Checklist
1. Immediately Patch Azure Linux Hosts
If you run Azure Linux, apply the latest kernel updates now. Microsoft’s advisory confirms the component is present, so there’s no reason to delay. Reboots will be necessary, so schedule accordingly.
2. Inventory Your Other Microsoft-Supplied Linux Artifacts
Make a list of all systems where you use a Microsoft-provided kernel or Linux image. Common candidates:
- Windows Subsystem for Linux 2 (check kernel version with uname -r inside WSL2 and compare to Microsoft’s source releases)
- Azure VMs using the linux-azure kernel (common in certain performance-optimized SKUs)
- AKS clusters with default or Microsoft-curated node images (check AKS release notes for kernel updates)
- Azure Marketplace images from Microsoft that include a custom kernel
3. Verify Module Presence
On each system, run lsmod | grep mlx5_core to see if the mlx5 driver is loaded. If you see output, your system could hit the bug during driver unload or shutdown. Also check dmesg for mlx5_core references to see if the driver is built into the kernel. If it is, the vulnerability footprint exists even if you aren’t using the hardware.
4. Check for Symptoms in Logs
Search kernel logs for patterns: refcount_t: underflow, mlx5_core, and call traces mentioning mlx5_destroy_flow_table or esw_acl_ingress_table_destroy. These are telltale signs the flawed code path was executed. If you see them without a crash, you may have been lucky; patch immediately.
5. Cross-Reference with Vendor Advisories
For non-Azure-Linux systems, check the advisory from your distribution maintainer. Ubuntu, Red Hat, Oracle, SUSE, and Amazon Linux have all issued updates. Map your running kernel version to the fixed version from your vendor. If your kernel is older, update. Even if your kernel is newer, confirm the fix commit is included.
6. Leverage CSAF/VEX Feeds Where Available
Subscribe to Microsoft’s VEX feed for Azure Linux to automate future advisories. For other products, watch for expanded coverage. In the meantime, if any of your critical infrastructure runs on Microsoft-supplied kernels that aren’t Azure Linux, prioritize manual verification; don’t wait for an advisory that may never come.
7. Set Up Proactive Monitoring
Ensure your log aggregation and alerting systems watch for kernel oops/panic events and specific mlx5-related patterns. This helps catch issues before the next reboot cycle.
8. Plan for Other Artifacts
If you manage custom VM images or container hosts that derive from Microsoft kernels, re-audit their kernel configuration. If CONFIG_MLX5_CORE or related options are enabled, and the kernel source predates the fix, you’re exposed.
Outlook: Broader Attestations and Supply Chain Maturity
Microsoft’s disclosure for CVE-2025-38109 illustrates the practical gap between vulnerability identification and enterprise action. As attack surfaces grow, machine-readable attestations like CSAF/VEX are set to become standard. The Azure Linux rollout is a proof point, but until Microsoft extends coverage to its other Linux artifacts, operations teams must fill the gap with old-fashioned verification.
We expect Microsoft to gradually add more products to its VEX program, but there is no published timeline. In the near term, transparency in software supply chains remains fragmentary. For CVE-2025-38109, the message is clear: patch what you can confirm, and investigate what you can’t.
This vulnerability isn’t a remote code execution nightmare, but it’s a sharp reminder that in a heterogeneous cloud environment, trust requires verification—and that verification is still far from automatic.