Microsoft has confirmed that its Azure Linux distribution is potentially affected by a kernel memory leak in the Microchip LAN743x Ethernet driver, tracked as CVE-2025-37909. While the advisory states that Azure Linux includes the implicated open-source library, the company has not ruled out that other Microsoft-distributed kernels—such as those used in Windows Subsystem for Linux 2 (WSL2) or Azure-tuned images—also contain the same vulnerable code.

What CVE-2025-37909 Actually Is

CVE-2025-37909 is a flaw in the Linux kernel’s lan743x driver, which supports Microchip LAN743x Ethernet controllers. Under specific conditions, the driver fails to properly free socket buffers (skbs) when Generic Segmentation Offload (GSO) is enabled. This causes a slow memory leak that can gradually degrade system performance and, over time, lead to out-of-memory conditions and loss of availability.

The vulnerability is a resource-exhaustion issue—not a remote code execution or data exfiltration risk. It requires local network traffic that triggers the buggy driver path, and the impact is primarily availability-focused. The upstream fix changes how skbs are mapped in the zero-fragment GSO case, ensuring they are attached to the correct descriptor and freed normally.

The bug was introduced in kernel commit 23f0703c (around the 4.17 era) and was patched in stable kernel releases, including 5.15.182 and several backported branches. The fix resides in the file drivers/net/ethernet/microchip/lan743x_main.c.

Microsoft’s Advisory: What It Confirms and What It Doesn’t

On the MSRC update guide, Microsoft acknowledges that Azure Linux includes the upstream code affected by CVE-2025-37909 and is therefore potentially vulnerable. The advisory also notes that Microsoft began publishing machine-readable Common Security Advisory Framework (CSAF) and Vulnerability Exploitability eXchange (VEX) documents in October 2025 to help customers automatically map CVEs to affected products.

Crucially, Microsoft states: “If impact to additional products is identified, we will update the CVE to reflect this.” That wording is precise—it’s an attestation of what Microsoft has verified so far, not an exhaustive list of every product that ships the lan743x driver. It tells customers: Azure Linux is confirmed in scope; for other Microsoft artefacts, the absence of an attestation is not proof of absence.

Where Else Could the Vulnerable Code Be Hiding?

Because the lan743x driver is part of the upstream Linux kernel, any Microsoft-distributed kernel image that built with CONFIG_LAN743X and a pre-fix commit could contain the bug. This includes:

  • WSL2 kernels: Microsoft ships distinct, independently versioned kernel builds for WSL2. These often include a broad set of upstream drivers, and if a WSL2 kernel was built from a tree predating the CVE fix and enabled the driver, it could be affected.
  • Azure-tuned kernels: Many Azure virtual machines run the linux-azure kernel, maintained by Canonical or other partners. These kernels are separate artefacts and may not yet include the backport unless the vendor has patched them.
  • Azure Marketplace images and AKS node images: Any appliance, container host, or specialized VM image that bundles a Linux kernel could carry the vulnerable driver, depending on the kernel’s version and configuration.
  • Other partner or first-party images: Microsoft publishes a variety of Linux-based images, including for IoT and edge deployments, that may embed the same upstream code.

Independent analyses echo this point: until Microsoft releases additional VEX/CSAF attestations or you verify the artefacts directly, you should treat any Microsoft kernel artefact as a potential carrier.

Assessing Your Exposure

For most organizations, the practical risk hinges on whether the vulnerable driver is present—and active—in the systems you operate. Start with a simple inventory.

Azure Linux users: Microsoft’s attestation makes these systems the confirmed priority. If you run Azure Linux VMs, treat them as in scope and patch immediately.

WSL2 endpoints: Check your WSL2 kernel version. From a WSL shell, run uname -r and compare it against Microsoft’s published kernel release notes. The WSL2 kernel source is public, and release tags can help you determine if a fix is included. Look for kernel config files in /boot or /proc/config.gz to see if CONFIG_LAN743X was set to ‘m’ or ‘y’.

Azure VMs and AKS nodes: Identify whether images are using vendor-supplied kernels or the linux-azure variant. Package names like linux-azure and their changelogs will tell you if the maintainer has backported the fix. Use grep -i LAN743X /boot/config-$(uname -r) to check the config.

Quick on-host checks:
- uname -r reveals the kernel release.
- sudo zgrep -i LAN743X /proc/config.gz or grep -i LAN743X /boot/config-$(uname -r) shows if the driver was enabled.
- ls /lib/modules/$(uname -r)/kernel/drivers/net/ethernet/microchip may list the lan743x.ko module.
- lsmod | grep lan743x tells you if the module is loaded.

Remember: a kernel can contain the driver without it being loaded. The vulnerability only manifests when GSO is enabled for a relevant interface and traffic patterns trigger the leak. Still, any system with the driver present in its kernel binary should be patched.

How to Patch and Protect Your Systems

Patch immediately: For Azure Linux, apply Microsoft’s published kernel updates and reboot. These updates should incorporate the upstream fix or a backported equivalent.

Expand your audit: Next, inventory all other Microsoft kernel artefacts—WSL2 kernels, linux-azure VMs, Marketplace images, AKS node images. For each, check the kernel configuration and map the kernel version to upstream commit IDs. Many distributions backport fixes without bumping the major version number, so rely on package changelogs or commit-ID mapping, not version strings alone.

Temporary mitigations: If you can’t patch right away, reduce exposure by disabling GSO on affected interfaces: sudo ethtool -K <ifname> gso off. This will impact network performance, so test carefully. In extreme cases, you might blacklist the lan743x module if no LAN743x hardware is present—but that’s a blunt tool with potential side effects.

Automate for the future: Integrate Microsoft’s CSAF/VEX feeds (and those from your Linux vendors) into your vulnerability management pipeline. Microsoft updates these machine-readable attestations as new product mappings are identified, giving you an automated signal when the scope of a given CVE changes.

The Bigger Picture: Linux Kernel CVEs and Microsoft’s New Transparency

CVE-2025-37909 is a textbook example of how Linux kernel vulnerabilities ripple through the software supply chain. A bug in a niche Ethernet driver ends up in cloud images, desktop Linux environments, and even the WSL2 kernel that powers developer workstations. Microsoft’s move toward CSAF/VEX attestations is a welcome step in making such dependencies machine-readable and actionable.

Yet the language in this advisory also illustrates the limits of current transparency. The statement “Azure Linux is affected” is clear and helpful. But for the IT professional managing a fleet of mixed OS images, the lack of definitive guidance on other Microsoft artefacts means manual verification remains necessary. Until every kernel artefact is attested, security teams must maintain their own artefact provenance inventories.

This patch cycle is a reminder to build or extend a kernel-artefact inventory that maps images, appliances, and kernel packages to upstream commit IDs. With that foundation, future CVEs become a deterministic query rather than a scramble for information.

As for CVE-2025-37909, the fix is straightforward. Patch Azure Linux first, audit and patch everything else second, and keep an eye on MSRC’s VEX updates—they may expand the scope as new inventories complete.