Microsoft has published an advisory confirming that its Azure Linux distribution includes vulnerable code for a memory leak in the Linux kernel’s ngbe network driver. Tracked as CVE-2025-37874, the flaw can cause gradual memory exhaustion and system instability if an attacker repeatedly triggers error paths in the driver. The fix, already merged into upstream kernel trees, is now rolling out to distributions—and Azure Linux users should apply it immediately.

The flaw: a small driver bug with a tangible stability cost

CVE-2025-37874 describes a missing memory-free operation inside the ngbe_probe() function of the wangxun ngbe Ethernet driver. When the kernel initializes the driver’s RSS settings via wx_init_rss_key(), it allocates a block of memory for wx->rss_key. If subsequent steps in the probe sequence fail, older code paths skipped freeing that allocation. Over time—if the driver is repeatedly probed and fails—this leaks kernel memory. The upstream fix adds a kfree(wx->rss_key) call in the error path and adjusts cleanup labels to prevent a potential double-free.

The bug is rated moderate severity with a CVSS v3 base score of 5.5, according to Amazon’s advisory. It is not remotely exploitable: an attacker needs local access to trigger the driver’s error conditions. The primary threat is denial of service through resource exhaustion, though a theoretical double-free could, in rare circumstances, lead to memory corruption.

Why Azure Linux is singled out—and what Microsoft’s phrasing doesn’t say

Microsoft’s advisory states that “Azure Linux includes this open-source library and is therefore potentially affected,” and adds that the company will update the CVE record if other products are found to carry the same code. This wording is part of Microsoft’s rollout of machine-readable CSAF/VEX attestations, which began in October 2025 to give customers clear per-product vulnerability statuses.

That phrasing is authoritative for Azure Linux: if you run Azure Linux images, the vulnerable driver code is present and you should patch. But it is not a blanket assurance that no other Microsoft product contains the ngbe driver. The same upstream kernel code could appear in:

  • WSL2 kernels: Microsoft ships a custom Linux kernel for Windows Subsystem for Linux 2. Whether that binary includes the ngbe driver depends on the build configuration and source tree version.
  • Azure Marketplace VM images based on other distributions (Ubuntu, Oracle Linux, etc.) may include the driver if their kernels are built with it.
  • Specialized Azure appliances or services that embed a Linux kernel could inherit the flaw.

Until Microsoft publishes a VEX statement declaring a product “Not Affected,” you should treat all Microsoft-shipped Linux kernels as potentially vulnerable. The company has committed to expanding VEX coverage, but for now, Azure Linux is the only product explicitly attested.

How we got here: upstream Linux, distributed kernels, and the VEX promise

The ngbe driver is part of the wangxun family of Ethernet drivers merged into the mainline Linux kernel several years ago. Like many kernel components, it can end up in diverse downstream builds maintained by cloud providers, appliance vendors, and distribution maintainers. Microsoft’s Azure Linux is a first-party distribution optimized for Azure workloads, and as a downstream consumer of the kernel, it inherited this bug.

Microsoft’s push toward structured vulnerability reporting marks a shift. Traditionally, cloud providers and software vendors left it to customers to guess which components were affected by a given CVE. With CSAF/VEX, Microsoft publishes a machine-readable file per product that states whether a CVE applies, is fixed, or is under investigation. For CVE-2025-37874, the Azure Linux VEX file will indicate “Known Affected,” triggering immediate action in vulnerability management pipelines that ingest these feeds. Microsoft plans to extend VEX to more products over time.

The advisory’s conditional language—“If impact to additional products is identified, we will update the CVE”—is both a statement of current inventory and a process guarantee. The security response team has scanned Azure Linux; they haven’t yet completed scans for every other Microsoft artifact that might embed a Linux kernel. Defenders should treat this as a live investigation, not a final verdict.

What to do right now

1. Patch Azure Linux immediately

If you use Azure Linux virtual machines, containers, or images, apply the vendor-provided kernel update as soon as it’s available in your package feeds. The fix is already upstream; Azure Linux’s maintainers typically backport critical fixes promptly. Schedule a reboot window and verify the kernel version post-update.

2. Audit other Microsoft-shipped Linux kernels

  • WSL2: Check your WSL kernel version. Microsoft periodically releases updated WSL kernels through Windows Update or manual download. Review release notes for mention of CVE-2025-37874, and install any pending kernel updates. If no explicit statement exists, you can verify locally: run lsmod | grep ngbe inside your WSL instance. If the module appears, the vulnerable code may be present.
  • Azure Marketplace images (non-Azure Linux): These are vendor-maintained. Check the respective distro’s advisory—Ubuntu, Red Hat, SUSE, Oracle, and Amazon Linux have all published pages for this CVE. Most provide kernel updates that include the fix.
  • Custom kernels on Azure VMs: If you built or deployed a custom kernel, verify whether it enables the ngbe driver (CONFIG_NGBE or similar). If yes, rebuild with the patched kernel source or disable the driver if you aren’t using Wangxun hardware.

3. Monitor Microsoft’s VEX feed for updates

Microsoft’s CSAF/VEX documents are published in the Security Update Guide alongside the advisory. Check the CVE page regularly for updates that might add new product attestations. Set up automated ingestion of VEX files into your security scanner or SIEM to receive alerts when the status changes for artifacts you use.

4. Compensating controls

  • Harden local access: Since exploitation requires local code execution, ensure strict user permissions and isolation on multi-tenant systems.
  • Monitor for ngbe errors: Watch system logs for repeated probe failures, ngbe-related kernel OOPS messages, or memory exhaustion warnings. These could indicate active attempts to trigger the leak or a misconfigured device.
  • Consider live patching: If your distro supports kernel live patching (e.g., Ubuntu Livepatch, RHEL kpatch), verify whether this fix is included. Live patching reduces downtime but may not cover all driver fixes.

What this means for security teams managing Microsoft ecosystems

CVE-2025-37874 is not the most critical kernel bug of the year, but it illustrates a broader challenge: keeping track of vulnerabilities in shared open-source components across a vendor’s product portfolio. Microsoft’s VEX approach, if consistently rolled out, will significantly reduce the guesswork. Until then, teams should treat any Microsoft-produced Linux artifact without an explicit “Not Affected” attestation as potentially impacted.

For Azure Linux customers, the message is clear: patch now. The advisory gives you the definitive signal. For everyone else, this CVE is a reminder to verify kernel compositions independently when vendor attestations are incomplete. The fix exists; the only remaining risk is failing to apply it where it’s needed.

Outlook: more VEX, less guesswork

Microsoft’s VEX program is still expanding. Expect more products to receive machine-readable vulnerability statuses in the coming months, easing the burden on security teams who currently parse prose advisories manually. For this specific CVE, watch for updates that may add Windows Subsystem for Linux, Azure Kubernetes Service node images, or other Linux-bearing products. The upstream kernel community, for its part, continues to patch similar driver bugs at a steady clip—each one a small fire that, with timely VEX data, becomes much easier to extinguish.

Apply the Azure Linux update now, audit your other Linux kernels, and keep an eye on Microsoft’s VEX feed. A little vigilance today will prevent a memory exhaustion headache tomorrow.