Microsoft has confirmed that Azure Linux is vulnerable to a newly disclosed kernel bug, CVE-2025-37755, but the company’s advisory stops short of declaring other Microsoft-distributed Linux artifacts safe. For admins running Azure Linux, the message is clear: patch immediately. For those managing other Microsoft-supplied kernels—including WSL 2, Azure Marketplace images, or custom VM builds—the situation is murkier. A local attacker can crash the system via a NULL-pointer dereference in the Wangxun Ethernet driver’s libwx library, and while Azure Linux is the only product Microsoft has explicitly attested as affected, other systems may carry the same vulnerable code.

What actually changed? A kernel NULL-pointer that crashes systems

On the Linux kernel’s networking stack, a helper function deep inside the Wangxun family of Ethernet drivers can fail to allocate memory and return a NULL pointer. Instead of handling that failure, the code barks a WARNON(!page) and then happily dereferences the NULL, triggering an immediate kernel panic or oops. The vulnerable path lives in drivers/net/ethernet/wangxun/libwx, a shared library used by drivers such as txgbe and ngbe. If your kernel was built with CONFIGLIBWX (set to y or m) and the relevant driver is loaded, the bug is present.

Microsoft’s Security Response Center (MSRC) published advisory CVE-2025-37755 and pointed to Azure Linux as a product that “includes this open‑source library and is therefore potentially affected.” The advisory is part of Microsoft’s CSAF/VEX rollout that began in October 2025, providing machine‑readable vulnerability attestations for its own software inventory. The good news: Azure Linux is now on the radar, and patches are being tracked. The catch: Microsoft’s language explicitly says that if other products are later found to ship the same kernel code, the CVE entry will be updated. That means anything else—WSL kernels, specialized Azure VM images, or embedded kernels in appliances—is in a gray zone until an attestation says otherwise.

What it means for you: the practical impact depends on what you run

The vulnerability can only be triggered locally, with an attack complexity that requires interaction with a network device bound to a Wangxun driver. In practical terms, an unprivileged user who can issue crafted packets or manipulate the device can panic the kernel, knocking the host offline. There’s no remote exploitation vector that transforms this into remote code execution; the main risk is denial of service.

If you manage Azure Linux instances (the Microsoft‑maintained CBL‑Mariner distribution), treat the advisory as authoritative. Your systems are affected. Apply the kernel updates Microsoft provides through the standard Azure Linux package channels as soon as they become available. Confirm the fix via the VEX/CSAF status change from “Known Affected” to “Fixed.”

For everyone else, the absence of an attestation for a product does not mean the product is safe. Consider these scenarios:

  • WSL 2 users and developers. The WSL 2 kernel is a separate artifact maintained by Microsoft. Check your kernel version inside WSL (uname -r) and examine the kernel config (/proc/config.gz or /boot/config-*). If CONFIGLIBWX is enabled, your kernel is vulnerable. Use the official WSL update mechanism (wsl --update) to fetch a patched kernel when Microsoft releases one.
  • Azure Marketplace image consumers. Many images—both official Microsoft offerings and third‑party images built on Microsoft kernels—may include the Wangxun drivers. Boot a test instance and run the checks below. If you find the vulnerable code, either apply vendor patches or rebuild the image with a corrected kernel.
  • Custom or bring‑your‑own kernels. If you build your own kernel for Azure or other environments, disable CONFIGLIBWX and related options unless your hardware specifically requires those drivers. For kernels you already deployed, rebuild with upstream fixes or with the config option turned off.
  • Security teams and compliance officers. Your vulnerability management playbooks should now include checks for CONFIGLIBWX and the associated driver modules. Relying on vendor advisories alone is insufficient when attestations are still rolling out.

How we got here: a supply‑chain gap and Microsoft’s phased transparency

The kernel bug itself is straightforward—a classic missing error‑handling path (CWE‑476) that upstream maintainers fixed months ago. Patches adding proper NULL checks have been merged into stable kernel trees and have trickled into distribution updates. The disclosure timeline underscores a pain point for operators: a patch in Git does not guarantee a patch in the kernel your system is actually booting. Each vendor must rebuild and redistribute, and Microsoft’s own attestation process is incremental.

Microsoft began publishing CSAF/VEX documents in October 2025 to give customers machine‑readable, product‑scoped vulnerability statements. Azure Linux was a natural starting point because it’s a flagship, actively maintained distro. The company has publicly committed to expanding VEX coverage as it completes inventories for other products. CVE‑2025‑37755 is one of the first tests of that promise: the advisory names Azure Linux, leaves the door open for others, and places the onus on customers to verify their own artifacts in the meantime.

What to do now: a practical checklist

Immediate steps for any team running Microsoft‑supplied kernels:

1. Inventory your kernels

List every running kernel and kernel artifact you manage—servers, containers that include a full kernel, WSL instances, marketplace images, custom snapshots.

2. Check for the vulnerable code

Run these commands on a live system or examine the kernel build configuration:

# Look for the config option
grep CONFIGLIBWX /boot/config-$(uname -r) 2>/dev/null || \
zcat /proc/config.gz 2>/dev/null | grep CONFIGLIBWX

If CONFIG

LIBWX=y or =m, check loaded modules lsmod | grep -E 'libwx|txgbe|ngbe|wx'

If you can’t access a running system, inspect the build configuration used when the image was created. A positive hit for CONFIGLIBWX means the helper is present and the kernel is potentially vulnerable.

3. Apply the fix

  • Azure Linux: Apply the latest kernel updates from the official repositories. Monitor MSRC for a “Fixed” VEX attestation.
  • Other Microsoft‑distributed kernels: Use the vendor’s update channel (e.g., wsl --update for WSL) when a patched kernel is released. If no update is yet available, mitigate with the steps below and contact Microsoft support for guidance.
  • Custom‑built kernels: Rebuild with the upstream fix applied. If the Wangxun hardware is not needed, simply disable CONFIGLIBWX.
  • Live patching: If your environment supports kernel live patching, check whether a livepatch addressing this specific NULL dereference is available and apply it as a temporary measure.

4. Mitigate until you can patch

  • Reduce local attack surface: Restrict shell or container access for untrusted users. Limit who can interact with host network devices.
  • Monitor aggressively: Set up alerts for WARNON(!page) messages in dmesg or system logs. Configure kernel crash capture (kdump) so you can detect and analyze any triggered panics.

5. Update your vulnerability playbook

Add kernel configuration checks for CONFIGLIBWX and sibling CONFIGTXGBE, CONFIGNGBE to your scanning routines. For WSL users, integrate WSL kernel version checks into endpoint vulnerability tools—the WSL kernel is updated outside standard package management and is easy to miss.

Outlook: a wider inventory is coming

Microsoft’s advisory for CVE‑2025‑37755 is a case study in modern vulnerability management: it gives clear direction for one product while leaving other assets in a state of uncertainty until attestations catch up. The company’s VEX program is still maturing, and customers should expect similar patterns for future kernel‑level CVEs. In the medium term, this is likely to improve as Microsoft expands its CSAF/VEX coverage across all Linux artifacts it ships. Until then, the safest posture is to assume any Microsoft‑supplied kernel image could contain the vulnerable driver and to verify your own configurations. Patches are straightforward, but only effective once the kernel you boot actually includes them.