Microsoft has published a security advisory for CVE-2025-39981, a use-after-free flaw in the Linux kernel’s Bluetooth management code, confirming that its Azure Linux distribution contains the vulnerable code. The advisory, part of Microsoft’s new machine-readable VEX/CSAF attestation pilot, only covers Azure Linux — leaving administrators who run WSL2, linux-azure virtual machines, or custom Marketplace images to conduct their own artifact-level investigations until Microsoft completes a broader product inventory.

The Vulnerability at a Glance

CVE-2025-39981 is a race condition in the Linux kernel’s net/bluetooth/mgmt.c file, where a struct mgmt_pending object can be freed while an asynchronous worker or callback still processes it. Public advisories from NVD, Debian, Ubuntu, Oracle Linux, and multiple enterprise vulnerability databases describe KASAN traces of slab use-after-free (UAF) triggered during Bluetooth management command handling. Upstream fixes introduce a validation flag and re-order list removal and free operations under appropriate locking, preventing callbacks from touching freed memory.

In practical terms, the bug is primarily an availability and stability issue. Kernel oopses, KASAN complaints, or host crashes are the likely symptoms. The attack surface generally requires local access or the ability to trigger MGMT command paths — for example, via socket calls to HCI interfaces — which limits the risk of remote code execution. However, in multi-tenant cloud environments where a VM host crash can cause broader disruption, the impact can be significant. Security researchers note that UAFs in kernel space can sometimes be escalated with careful heap grooming, so timely patching is prudent.

Microsoft’s Advisory: What It Says — and What It Doesn’t

On its Security Update Guide, Microsoft states that Azure Linux includes the affected open-source library and is therefore potentially affected. The company also notes that it began publishing CSAF/VEX attestations for Azure Linux in October 2025 as a commitment to transparency. The advisory text explicitly says: “If impact to additional products is identified, we will update the CVE to reflect this.”

That phrasing is deliberate and tied to Microsoft’s phased rollout of machine-readable vulnerability disclosures. The initial VEX pilot targets Azure Linux to provide immediate, automated signals to the large population of Azure VM customers. The company has committed to expanding attestation coverage to other products over time, but as of this writing, no other Microsoft product — including WSL2, linux-azure kernel packages, or specialized VM images — has been publicly attested.

Critically, this does not mean those products are free of the vulnerable code. Kernel features are built artifact-by-artifact: whether a Microsoft binary includes the Bluetooth MGMT code depends on the kernel version, the upstream commit range, and the CONFIG_* flags chosen at build time. Different artifacts can therefore differ in exposure. Until Microsoft scans and attests them individually, the absence of a VEX statement is not evidence of absence.

Why Your WSL2 or linux-azure VM Might Be Affected

Several Microsoft-maintained or -distributed artifacts could, in principle, contain the same vulnerable code:

  • WSL2 kernel images: Windows Subsystem for Linux 2 ships a Microsoft-maintained kernel binary. If that kernel build enables Bluetooth support with the same configuration, it could carry the UAF bug.
  • linux-azure kernel packages: Certain Azure VM image pipelines or curated images use specialized linux-azure kernels that share backports or stable upstream commits with Azure Linux, potentially including the affected mgmt.c code.
  • Marketplace VM images and appliances: Many Azure Marketplace offerings embed kernels or kernel modules. These are independently built artifacts; they are not covered by the Azure Linux attestation unless the publisher explicitly provides their own VEX data.

Even within Azure Linux itself, the fix may vary by kernel version. Microsoft’s advisory does not list specific patched image versions in its VEX file — operators must cross-reference their running kernel with the distro’s package repository and changelog.

What This Means for You

The impact differs depending on your role:

For home users and WSL2 enthusiasts: If you rely on WSL2 for development or personal projects, the risk is low but not zero. A local attacker with shell access inside a WSL instance might theoretically trigger the bug, though the containment of WSL2’s lightweight VM may limit the blast radius. Check your WSL2 kernel version and apply any available Windows updates that bump the kernel binary. Disabling Bluetooth modules if unused is a simple mitigation.

For cloud administrators and DevOps teams: If you manage Azure Linux VMs, treat Microsoft’s attestation as authoritative and patch immediately. The VEX data can be ingested into vulnerability scanners to automate triage. For non-Azure-Linux Microsoft images — such as linux-azure nodes, AKS worker node custom images, or partner appliances — you cannot rely on the Azure Linux attestation. Each must be verified independently. In multi-tenant environments, where a host crash could affect many workloads, prioritize patching and consider disabling Bluetooth kernel modules if you cannot update right away.

For security analysts and vulnerability managers: This advisory highlights the operational gap between a vendor’s initial VEX release and comprehensive product coverage. You should build processes to track Microsoft’s expanding CSAF feed and maintain an inventory of every kernel artifact you run, along with its provenance. When an attestation is missing, manual inspection of kernel config and source may be necessary.

How We Got Here

The Linux kernel Bluetooth MGMT use-after-free was first reported by kernel developers using KASAN instrumentation, and upstream patches were merged into the mainline and stable trees. The vulnerability was assigned CVE-2025-39981 and published by the CVE Program in October 2025. Distribution maintainers quickly backported the fix into their respective kernel packages.

Microsoft, meanwhile, had been preparing a shift toward machine-readable security advisories. In October 2025, the Microsoft Security Response Center announced a pilot program to publish CSAF/VEX attestations, starting with Azure Linux. The goal was to give Azure customers programmatic, high-confidence signals about whether a CVE affects the software packages they actually run, reducing noisy “potentially affected” blanket alerts. As a result, when CVE-2025-39981 came to light, Microsoft issued an attestation for Azure Linux but did not yet have the internal scanning infrastructure to make definitive statements about dozens of other Microsoft-built kernel artifacts. That work is ongoing.

Your Action Plan

A practical timeline for securing your environment:

  1. Identify Azure Linux instances immediately. Run uname -r on VMs and check whether your kernel package matches the latest Azure Linux release. Apply updates through your normal distro update mechanism. If you use vulnerability scanners, configure them to ingest Microsoft’s VEX/CSAF feed for automated detection of affected Azure Linux images.

  2. Inventory all other Microsoft-supplied kernel artifacts. Include WSL2 kernel binaries, linux-azure images from Azure Marketplace, custom VM node images, and any Docker containers that ship a full kernel. For WSL2, check the kernel version with wsl --status or uname -r inside the WSL instance. Compare against published Windows update records to see if a newer kernel binary has been delivered.

  3. For artifacts where Microsoft has not published an attestation, perform per-artifact verification. Methods include:
    - Inspecting the kernel config (zcat /proc/config.gz or examining the boot config) for CONFIG_BT and related options.
    - Searching for the vulnerable source file or symbols (mgmt_pending, mgmt_pending_valid) in kernel module binaries or debug information, if available.
    - Contacting the image publisher or checking their own advisory feeds.

  4. Apply mitigations if patching is delayed. On hosts that do not require Bluetooth, blacklist the module by adding blacklist bluetooth to /etc/modprobe.d/blacklist-bluetooth.conf or disable the service. Restrict local untrusted workloads’ access to HCI/MGMT sockets via appropriate SELinux, AppArmor, or seccomp policies.

  5. Automate future VEX ingestion. Subscribe to Microsoft’s CSAF/VEX feed and your Linux distribution’s advisory feed. Configure your vulnerability management platform to flag when a product previously not attested suddenly receives an affected status — this will catch any future expansion of coverage.

  6. Maintain an artifact registry. Long-term, document which images and kernel versions you run across your fleet, including build provenance. When the next kernel CVE hits, you will be able to answer “Am I exposed?” in minutes rather than days.

Outlook

Microsoft has publicly committed to expanding VEX/CSAF coverage beyond Azure Linux, and given the growing industry shift toward machine-readable advisories, it is likely that WSL2, linux-azure, and other artifacts will eventually receive their own attestations. Until then, the safest posture is to treat the Azure Linux advisory as a limited-scope confirmation and to verify everything else yourself. By combining vendor-provided automation with conservative per-artifact checks, you can close the “attestation gap” without compromising operational continuity.