On March 5, Microsoft officially confirmed that Azure Linux is potentially affected by CVE-2025-22109, a memory leak flaw buried deep in the Linux kernel’s AX.25 networking stack. The advisory, posted to the Microsoft Security Response Center (MSRC), marks the company’s first machine-readable CSAF/VEX attestation for this vulnerability—but it pointedly does not clear any other Microsoft product. That leaves WSL2, AKS node images, linux-azure kernels, and countless Marketplace VMs in a security gray zone, forcing admins to perform their own artifact-level verification.

The Flaw at a Glance

CVE-2025-22109 centers on a broken “autobind” feature in the kernel’s AX.25 socket implementation. AX.25 is a protocol used primarily by amateur radio enthusiasts; it’s not something most enterprise Linux deployments actively use. However, because the vulnerable code path (net/ax25) is compiled into many default kernel builds, the bug can lurk unseen.

Upstream kernel maintainers discovered the issue via kmemleak and Syzkaller fuzzing. The autobind routine was failing to increment reference counts correctly, causing memory leaks and refcount errors in ax25connect and ax25release. After analysis, they concluded the feature couldn’t be fixed reliably and simply removed it. The upstream patch, titled “ax25: Remove broken autobind,” ensures that calling connect() without an explicit bind() now returns -EINVAL instead of leaking resources. Multiple distros—including Ubuntu and SUSE—have since backported the fix, assigning a CVSS v3 score of 5.5 (medium severity).

The impact is strictly local: an attacker would already need code execution to exercise AX.25 sockets and cause kernel resource exhaustion, leading to instability or crashes. There’s no remote exploitation vector, and no public evidence points to a wormable attack chain.

Who’s Impacted – And Who Isn’t (Yet)

Microsoft’s advisory is unambiguous for Azure Linux: “Azure Linux includes this open-source library and is therefore potentially affected.” That’s a clear signal. If you run Azure Linux, you’re in scope and should apply the vendor’s kernel update immediately.

But the advisory’s second sentence is equally important: “If additional Microsoft products are identified as including the affected code, we will update this CVE accordingly.” This is not a statement of safety for those other products. It’s a procedural promise to expand attestations later. In the meantime, the following Microsoft artifacts remain unchecked:

  • WSL2 kernels – Microsoft ships a custom Linux kernel for Windows Subsystem for Linux 2; it’s a separate build from Azure Linux and may include AX.25 modules.
  • linux-azure kernel packages – used in some Azure VM SKUs; configuration may differ from the Azure Linux (CBL-Mariner) lineage.
  • AKS node images – both the default Ubuntu-based and Azure Linux-based node images; some may use linux-azure kernels.
  • Marketplace VM images – including older or third-party published images that bundle Linux kernels.
  • Container images and appliances – any artifact that includes a Linux kernel, whether as a host or as a statically compiled binary.

Absence of a public VEX/CSAF attestation for these artifacts does not mean they are free of the vulnerable code. It means Microsoft hasn’t yet completed the inventory and mapping for them. Without your own inspection, you’re flying blind.

Why Microsoft’s Narrow Advisory Makes Sense

Large vendors roll out machine-readable vulnerability attestations in phases for a practical reason: mapping every product, image, kernel configuration, and appliance across a global cloud ecosystem is a monumental task. Microsoft chose Azure Linux as the first product family for its CSAF/VEX publication, likely because it’s the company’s own Linux distribution and a critical component of many Azure services. That initial attestation gives Azure Linux customers a head start on automated triage and patching.

But the phased approach also creates a dangerous assumption: that everything else is automatically clean. Microsoft’s language deliberately avoids that implication. The company’s commitment to “update the CVE if additional Microsoft products are identified” is a forward-looking promise, not a present-tense guarantee. Until those updates appear, you must treat all non-Azure-Linux artifacts as unknowns.

How We Got Here: A Timeline of Gaps

  • Upstream discovery – Kernel developers found the AX.25 leak via automated fuzzing tools. The fix landed in mainline and was backported to stable kernels.
  • Distro advisories – Ubuntu, SUSE, and others published their own advisories, confirming the vulnerability and providing patched kernels.
  • Microsoft’s VEX rollout – Microsoft committed to publishing machine-readable security advisories for open-source components used in its products. CVE-2025-22109 became an early test case for that process, with Azure Linux as the first attested product.
  • Current state – The MSRC advisory is live, but only for Azure Linux. All other Microsoft products lack a formal attestation, leaving a verification gap that falls on customers.

Action Plan: Patch, Scan, or Assume the Worst

1. Patch Azure Linux Immediately

If you run Azure Linux VMs or AKS node images based on Azure Linux, follow Microsoft’s published guidance. Apply the kernel update and reboot. This closes the gap for all attested images.

2. Inventory All Other Microsoft Artifacts

List every Linux-based asset in your environment that could be using a Microsoft-supplied kernel. This includes:

  • WSL2 instances (check wsl.exe --list --verbose)
  • AKS node pools (verify the node image SKU)
  • Virtual machines using linux-azure kernels (uname -r shows -azure suffix)
  • Any Marketplace image that relies on a Microsoft-published kernel
  • Containers and serverless functions running on Linux hosts

3. Verify Each Artifact Individually

For each asset, determine whether the AX.25 code is present. On a running system, use these commands:

# Check kernel version
uname -r

Look for CONFIGAX25 in kernel config

zgrep CONFIGAX25 /proc/config.gz

or for some systems:

grep CONFIGAX25 /boot/config-$(uname -r)

Check if ax25 module exists

modinfo ax25

Inspect module filesystem paths

ls /lib/modules/$(uname -r)/kernel/net/ax25/

If CONFIGAX25=y or =m appears, or if the module exists, the kernel includes the vulnerable code path and must be patched or rebuilt.

For containers and appliances, use software composition analysis (SCA) tools and SBOM inspection. Many scanners (Trivy, Grype, Syft) can detect CVE-2025-22109 in container image layers. For statically compiled binaries, check if the binary bundles an affected kernel tree; if so, the binary must be rebuilt with a patched toolchain—simply updating the host kernel won’t help.

4. Apply Compensating Controls

If you can’t patch immediately, reduce the attack surface:

  • Block loading of the ax25 module: echo "blacklist ax25" >> /etc/modprobe.d/blacklist-ax25.conf
  • Use network isolation and process-level restrictions to limit who can execute socket operations.
  • Monitor kernel logs for OOPS messages or memory leak warnings, and collect vmcore dumps before rebooting if you suspect active exploitation.

5. Prioritize Multi-Tenant and Public-Facing Hosts

Systems hosting multiple customers or accessible from less-trusted networks carry higher risk. Patch these first.

The Bigger Picture

CVE-2025-22109 isn’t a panic-inducing vulnerability; it’s a local, medium-severity memory leak that requires existing code execution. But it exposes a broader truth about modern software supply chains: a vendor’s initial security advisory rarely covers every artifact you run. Microsoft’s phased VEX approach is a step toward machine-readable transparency, but it places the onus on you to verify everything outside the attested scope.

Watch for updated CSAF/VEX documents from Microsoft in the coming weeks. If the company identifies AX.25 code in WSL kernels, linux-azure packages, or AKS node images, expect those products to appear in the CVE entry. In the meantime, treat your non-Azure-Linux workloads as guilty until proven innocent. A few minutes of inspection now beats an unplanned outage later.