On July 5, 2025, Microsoft’s Security Response Center published an advisory for CVE-2025-38644, a Linux kernel vulnerability that can cause system instability and denial of service through malformed wireless TDLS operations. The advisory states that “Azure Linux includes this open-source library and is therefore potentially affected” — but it does not assess any other Microsoft-supplied Linux kernels, including those used by WSL2, the linux-azure kernel package, and many Azure Marketplace images. Administrators running those unlisted kernels must perform their own verification to determine exposure.

The Advisory: One Product Named, Many Left in Limbo

The MSRC entry for CVE-2025-38644 is a machine-readable CSAF/VEX attestation, part of Microsoft’s growing effort to provide automated vulnerability management signals. Azure Linux is explicitly flagged as a carrier of the vulnerable mac80211 component. The advisory language is precise: Microsoft has inspected Azure Linux build artifacts and confirmed the presence of the affected library. It does not make any claims about other products.

For Azure Linux customers, this is an authoritative signal to patch. For everyone else who runs Microsoft-supplied Linux kernels — including the linux-azure kernel inside many Azure VMs, the kernel used by Windows Subsystem for Linux 2 (WSL2), and kernels baked into Marketplace appliance images — the absence of an attestation is not proof of safety. These artifacts remain unassessed, and may contain the same vulnerable code depending on how they were built.

Who’s Affected? It Depends on Your Kernel

The vulnerability lives in the mac80211 wireless subsystem, specifically in the TDLS (Tunneled Direct Link Setup) handshake. The upstream fix, merged into the Linux kernel in mid-2025, adds a simple guard: if a station is not in station mode or not fully associated, TDLS operations are rejected immediately. Without that guard, an NL80211 control message can trigger a kernel warning (WARN_ON) — and potentially a crash — because TDLS peer state is never initialized.

The practical impact varies by audience:

  • Azure Linux users: You are affected. Microsoft has confirmed your distribution carries the vulnerable code. Patch immediately using the channels Microsoft provides.
  • Azure VM users running a non-Azure Linux distribution (e.g., Ubuntu, RHEL) with the linux-azure kernel: Your kernel likely includes mac80211 code. Check your kernel configuration and changelogs; most major distributions have already shipped the backport. If you haven’t updated recently, you may be exposed.
  • WSL2 users: The Microsoft-provided WSL2 kernel is built from a configurable tree. Older WSL2 kernels may have CONFIG_MAC80211 enabled and thus carry the bug. Verify your WSL kernel version and update if necessary.
  • Windows administrators: The vulnerability itself is in Linux kernel code, so Windows itself is not directly affected. However, if you allow untrusted code to run inside WSL2 instances, an attacker with local access could potentially trigger the flaw to crash the WSL2 kernel, disrupting Linux workloads.

Why TDLS and Wi-Fi Code Matters Even on Servers

You might wonder: why worry about Wi-Fi stack bugs on cloud servers or virtual machines that don’t even have wireless hardware? The answer lies in how the Linux kernel is built. Many kernel configurations enable the full mac80211 framework by default, even when no wireless adapter is present — because the code is part of the same monolithic kernel image or a loadable module. An attacker who can run code on the system (even inside a container or WSL2 instance) might be able to send crafted NL80211 messages to trigger the bug, causing a local denial of service.

Microsoft’s own advisory rates the availability impact as “total”: an attacker could fully deny access to resources in the impacted component. While no public exploit code is circulating, the bug was discovered by the syzbot fuzzer, and such fuzzed crash cases often attract attention from malicious actors. Patching proactively is the safest course.

From Syzbot to Patch: A Quick History

  • Mid-2025: The syzbot kernel fuzzer found an ordering problem in mac80211 where NL80211_TDLS_ENABLE_LINK could be sent before association completed, leaving sdata->u.mgd.tdls_peer uninitialized.
  • Upstream fix: Kernel developers merged a patch that rejects TDLS operations when the station is not associated. The commit IDs are tracked by multiple Linux distributors.
  • Distribution mapping: Debian, SUSE, and others quickly backported the fix into their stable kernel trees and issued advisories.
  • July 5, 2025: Microsoft published its CSAF/VEX attestation, naming Azure Linux as affected and reserving the right to update the record if other products are found to be vulnerable.

Your 4-Step Verification Checklist

If you manage any Linux system that originated from a Microsoft channel, run through these steps to determine your exposure:

  1. Check kernel version and loaded modules
    bash uname -r lsmod | grep -i mac80211
    If mac80211 appears in the module list, the vulnerable code is present and loaded.

  2. Inspect kernel configuration
    bash zgrep CONFIG_MAC80211 /proc/config.gz # or cat /boot/config-$(uname -r) | grep -i mac80211
    A value of y or m means the code is compiled in. Even if the module is not currently loaded, it could be activated.

  3. Search distribution changelogs for the CVE or upstream commit
    bash # Debian/Ubuntu apt changelog linux-image-$(uname -r) | grep -i 38644 # RHEL/CentOS rpm -q --changelog kernel | grep -i 38644
    If your changelog mentions CVE-2025-38644 or the upstream commit message, you are patched.

  4. For offline images (VHDs, snapshots)
    Mount the image and inspect /lib/modules/<version>/ for mac80211.ko or /boot/config-<version> for the CONFIG_MAC80211 flag.

If you find the vulnerable code and no evidence of a fix, plan a kernel update immediately.

Patching and Mitigation Options

Patch where you can
- Azure Linux: Follow Microsoft’s guidance and install the updated kernel packages referenced in the VEX attestation.
- Ubuntu, RHEL, SUSE VMs on Azure: Pull the latest kernel updates from your distribution’s package manager. Most have already shipped the backport.
- WSL2: Check for a newer WSL2 kernel from Microsoft’s GitHub releases or update via wsl --update.

Short-term mitigations
If patching is delayed and you can afford to lose wireless functionality:
- Blacklist the wireless modules: echo 'blacklist cfg80211' >> /etc/modprobe.d/blacklist-cve-2025-38644.conf and echo 'blacklist mac80211' >> /etc/modprobe.d/blacklist-cve-2025-38644.conf, then reboot.
- On systems that never need Wi-Fi, you can rebuild the kernel with CONFIG_MAC80211=n, but this is usually overkill.

Detection and monitoring
- Watch kernel logs (dmesg or /var/log/kern.log) for WARN_ON backtraces containing ieee80211_tdls_oper or mac80211. A triggered exploit will leave this signature.
- Set up SIEM rules to alert on repeated wireless subsystem errors or unexpected reboots that correlate with these kernel symbols.

The Bigger Picture: Microsoft’s Evolving Transparency

Microsoft’s move to publish machine-readable CSAF/VEX attestations is a genuine step forward for enterprise vulnerability management. It allows teams to automate triage and prioritization, and it signals that Microsoft is taking Linux security seriously — not just for Azure Linux, but for all the Linux kernels it ships.

But this incident highlights the gap between a single-product attestation and a complete inventory. With WSL2, linux-azure, and countless Marketplace images in play, Microsoft’s silence on those artifacts forces administrators to fill the verification void themselves. The company has stated it will update records if other products are found vulnerable. Until those updates arrive, treat unfamiliar kernels from Microsoft as “unknown,” not “safe.”

For Azure Linux customers, this advisory is your cue to patch. For everyone else, it’s a reminder that the kernel under your feet might be carrying more code than you think — and that verifying your supply chain is a non-negotiable part of cloud security.