Microsoft has confirmed that its Azure Linux distribution ships a Linux kernel component vulnerable to a null-pointer dereference that can crash hosts running VXLAN with proxy enabled. The flaw, tracked as CVE-2025-39850, was fixed upstream, but Microsoft’s advisory says only Azure Linux has been verified as affected so far — leaving open the possibility that other Microsoft-provided kernels and images may also contain the buggy code.

If you run virtual networks in Azure, Kubernetes nodes, or WSL2 and have VXLAN proxy turned on, an unpatched kernel can be felled by a crafted network packet that triggers a kernel oops. The result isn’t remote code execution, but an abrupt host crash that can ripple through multi-tenant environments.

What Exactly Is Broken?

VXLAN, the Virtual Extensible LAN protocol, lets you build overlay networks across Layer 3 boundaries. It’s a cornerstone of cloud software-defined networking, used heavily in Azure, Kubernetes, and OpenStack. When you enable the VXLAN proxy option, the kernel can respond to ARP and IPv6 Neighbor Discovery requests on behalf of virtual machines, reducing broadcast traffic.

The bug lurks in how the kernel handles Forwarding Database (FDB) entries. Normally, an FDB entry points to a single remote destination. But if the entry refers to a nexthop group — a collection of paths — the code failed to check for a valid remote pointer. When the proxy logic tried to dereference the null pointer, the kernel panicked.

Upstream developers fixed the problem by adding existence checks before the dereference and by dropping packets earlier when the remote destination couldn’t be resolved. The patch is small and targeted, making it straightforward for Linux distributions to backport. According to Microsoft’s Security Response Center (MSRC), the vulnerability specifically affects the Linux kernel VXLAN implementation, and Azure Linux is the one Microsoft product they’ve publicly listed as “potentially affected.”

What It Means for You

For Azure Administrators and Cloud Engineers

If you manage Azure virtual machines or Azure Kubernetes Service (AKS) clusters, the immediate concern is whether your node images carry an unpatched kernel. Microsoft’s attestation names Azure Linux, but the company itself warns that it will update the inventory if other products are found to have the same vulnerable code. That means you can’t assume your Ubuntu, CentOS, or Windows-supplied WSL kernels are safe just because they aren’t explicitly listed.

Key point: The crash is a denial-of-service risk. On a multi-tenant host, one malicious or misconfigured VM could take down the entire physical node, affecting all tenants on that hardware. Even in single-tenant setups, an unexpected reboot disrupts services.

For DevOps and Kubernetes Teams

If your AKS node pools use an Azure Linux image (or any image derived from Microsoft’s kernel packages), check whether the VXLAN module is loaded. Kubernetes networking plugins like Calico or Flannel may not use VXLAN by default, but if you’ve chosen that overlay mode, the proxy option might be active. The same applies to self-managed clusters on Azure VMs.

For Windows Users Who Run WSL2

WSL2 ships its own Linux kernel, often updated via Windows Update or manually. If you use WSL for development and have enabled advanced networking features or custom kernels, the VXLAN module could be present. A crash inside WSL2 typically doesn’t bring down Windows, but it can kill all your running Linux instances and cause data loss.

How We Got Here

VXLAN has been part of the Linux kernel since version 3.7, released in 2012. The proxy feature was added later to improve ARP handling in large overlay networks. The null-pointer bug was reported through public vulnerability channels and assigned CVE-2025-39850. Upstream maintainers committed the fix to the mainline kernel, and distributions began integrating it.

Microsoft’s handling of open-source CVEs has evolved. The company now publishes machine-readable CSAF/VEX attestations that let security tools automatically determine whether a given product is affected. For this CVE, Microsoft’s advisory explicitly says: “Azure Linux includes this open-source library and is therefore potentially affected.” It also promises to update the entry if other Microsoft products are found to be vulnerable. That’s not a guarantee of safety for non-Azure-Linux users—it’s an honest acknowledgment that inventory checks are ongoing.

The timeline:
- Upstream fix merged: Date not publicly disclosed in detail, but fixes have been backported by major distributions.
- Microsoft advisory published: The MSRC update guide for CVE-2025-39850 is live, with the Azure Linux attestation.
- No fixed package versions yet: At the time of writing, Microsoft hasn’t listed specific Azure Linux kernel builds that contain the fix, so administrators must rely on changelogs and distribution-vendor advisories.

What to Do Now

1. Inventory Your Linux Kernels and Images

Start by listing every Linux system in your environment that comes from Microsoft or runs in Azure:
- Azure VMs (both Microsoft-published images and custom ones)
- AKS node images (check the OS and kernel version with kubectl get nodes -o wide)
- WSL2 kernels (run uname -r inside WSL)
- Any on-premises systems running Azure Stack HCI or hybrid solutions that use Microsoft-provided kernels

2. Check for VXLAN Presence and Status

On each suspect host, run:

uname -r
lsmod | grep vxlan
modinfo vxlan

If the module is loaded or built-in, and your network configuration uses VXLAN tunnels, you may be exposed. Look for proxy in VXLAN device settings:

ip -d link show <vxlan-interface>

3. Search for Evidence of Crashes

Scan kernel logs for past oops messages related to VXLAN:

journalctl -k | grep -iE 'vxlan|vxlan_xmit|arp_reduce|neigh_reduce'

Any mention of null pointer dereference or kernel BUG at vxlan_xmit is a strong sign you’ve been affected.

4. Get Patched Kernels

  • Azure Linux: Microsoft’s attestation doesn’t list fixed versions yet. You’ll need to check your specific distribution’s repository (e.g., Mariner, from which Azure Linux descends). Run apt changelog linux-image-$(uname -r) or rpm -q --changelog kernel-$(uname -r) and look for references to CVE-2025-39850 or upstream commits that fix VXLAN null-pointer issues.
  • Other distributions on Azure VMs: If you use Ubuntu, Debian, SUSE, etc., consult the distro’s security tracker. Many have already issued fixes (e.g., Ubuntu USN, Debian DSA, SUSE SUSE-SU).
  • AKS node images: Microsoft periodically refreshes node images with updated kernels. Check the AKS release notes and node image version history. You can force a node image upgrade via az aks nodepool upgrade with --node-image-only.
  • WSL2: Update your WSL kernel via wsl --update or download the latest package from Microsoft’s WSL GitHub releases.

5. Mitigate If You Can’t Patch Immediately

  • Disable VXLAN proxy on any unpatched host: ip link set dev <vxlan> proxy off
  • Restrict access to network configuration tools to trusted administrators only.
  • Move multi-tenant workloads to already patched hosts or dedicated hardware.
  • For AKS, consider temporarily disabling VXLAN-based network plugins if your cluster can tolerate a brief outage.

6. Validate the Fix

After updating the kernel and rebooting, verify:
- The module version or package changelog references the fix.
- Kernel logs no longer show VXLAN oopses.
- In a test environment, reproduce the crash scenario (if possible) to confirm it’s blocked.

Outlook

Microsoft’s machine-readable vulnerability attestations are a step forward for transparency, but they’re only as good as the inventory behind them. Until Microsoft explicitly clears other products — or extends the “affected” list — everyone running a Linux kernel provided by Microsoft on Azure or elsewhere should verify their exposure. The company’s stance leaves a grey area that prudent IT teams won’t ignore.

The fix is simple; the logistical challenge is rolling it out across fleets of VMs, containers, and developer machines. Expect Microsoft to publish more granular patch versions in its advisories as internal validation completes. In the meantime, the safest approach is to treat any Microsoft-derived kernel with VXLAN proxy enabled as potentially vulnerable and to prioritize patching hosts that carry untrusted or multi-tenant workloads.