Microsoft has issued an advisory for CVE-2024-35870, a use-after-free vulnerability in the Linux kernel’s CIFS/SMB client, stating that Azure Linux “includes this open-source library and is therefore potentially affected.” The advisory, published on the Microsoft Security Response Center (MSRC) portal, stops short of listing any other Microsoft products as affected—but that doesn’t mean they’re safe. For administrators and users running Microsoft-supplied Linux images beyond Azure Linux, the advisory raises a critical question: what about WSL2 kernels, Azure Marketplace images, and other embedded Linux instances?

The vulnerability: what’s broken and how it was fixed

CVE-2024-35870 is a memory-corruption flaw in the Linux kernel’s CIFS/SMB client implementation. Specifically, a race condition in the smb2_reconnect_server() function can lead to a use-after-free when a reconnect worker accesses a session that another thread is tearing down. If exploited, it can trigger a kernel general protection fault, crashes, or potentially allow privilege escalation. The Linux kernel maintainers patched the issue in stable releases 6.6.29, 6.8.5, and later, and the exact commits are recorded in the kernel mailing list. Downstream distributors—Debian, Ubuntu, Oracle, Amazon Linux—have since released their own advisories and fixed kernel packages.

The technical risk depends on two things: whether a given kernel build includes the CIFS client code (compiled in or as a loadable module) and whether the vulnerable code path is reachable. An attacker would typically need local access and the ability to mount or interact with CIFS shares under specific session states. Nonetheless, kernel use-after-free bugs are consistently treated as serious because they can be chained with other exploits to gain elevated privileges.

Microsoft’s precise wording—and why it doesn’t let others off the hook

Microsoft’s advisory says: “One of the main benefits to our customers who choose to use the Azure Linux distro is the commitment to keep it up to date with the most recent and most secure versions of the open source libraries with which the distro is composed.” It then clarifies that Azure Linux includes the vulnerable library and is potentially affected. This is a per-product attestation, part of Microsoft’s new vulnerability exploitability eXchange (VEX)/Common Security Advisory Framework (CSAF) program, launched in October 2025 to give machine-readable, product-scoped vulnerability statuses.

Crucially, the advisory adds: “If impact to additional products is identified, we will update the CVE to reflect this.” In other words, only Azure Linux has been formally inventoried so far. Other Microsoft artifacts—WSL2 kernels, custom cloud-optimized kernels, Linux-based appliances, IoT/edge images, and Marketplace virtual machine images—have not yet been attested. The absence of an attestation is not proof of safety; it means verification hasn’t been completed.

How to verify if your Microsoft Linux images are at risk

You can’t rely on the single advisory to rule out exposure. Instead, check each Linux image or virtual machine you run that comes from Microsoft. The key variables are kernel version, configuration, and the presence of the CIFS module.

For Azure Linux users

If you run Azure Linux virtual machines or scale sets, Microsoft’s attestation is your authoritative signal. Patch immediately using the latest kernel updates from the Azure Linux repository. No further verification is needed.

For everyone else—especially WSL2

WSL2 distributions run a Microsoft-provided Linux kernel. Although the kernel is often trimmed, it may still include CIFS support. Check your WSL2 kernel version and module list:

wsl --status          # from Windows command line
uname -a              # inside WSL2
zgrep CONFIG_CIFS /proc/config.gz   # if config.gz exists
lsmod | grep cifs      # see if cifs.ko is loaded

If CIFS is present and the kernel version is older than the patched stable versions (e.g., before 6.6.29 or 6.8.5), your system is potentially vulnerable. The same command set applies to any Linux virtual machine, container host, or appliance you suspect may be running a Microsoft-sourced kernel.

For custom or Marketplace images

Images from the Azure Marketplace may include kernels from various publishers. Even if the publisher is Microsoft, the kernel could be a derivative. Gather the kernel version and .config, then cross-reference with the upstream fix commits. If your vendor hasn’t published an attestation, you’ll need to do your own inspection.

What to do right now

Patch and verification timelines depend on your environment and risk tolerance.

  1. Patch Azure Linux immediately. Microsoft’s advisory confirms exposure; treat it as urgent.
  2. Inventory all other Microsoft-supplied Linux artifacts. WSL2 kernels, IoT devices, and any Marketplace images you’ve deployed. Record kernel versions and CIFS status.
  3. For each unpatched artifact that includes CIFS, restrict access. Disable CIFS mounts if they aren’t needed. On shared systems, prevent unprivileged users from mounting shares or loading kernel modules. Monitor kernel logs for CIFS errors (messages containing smb2_reconnect_server or CIFS VFS) which could indicate attempted exploitation.
  4. Watch for updated attestations. The Microsoft VEX/CSAF program is expanding. Subscribe to the MSRC advisory feed or relevant CSAF feeds to get automated updates when new products are covered.
  5. Consider backports. If you maintain custom kernels, locate the commit IDs from the Linux kernel announcement and apply them to your branch. Many stable trees already include the fix; verify your specific tree.

How we got here: the rise of VEX/CSAF and phased rollouts

The Linux kernel vulnerability itself is a typical example of a use-after-free in complex driver code. What’s new is the way vendors like Microsoft are communicating about open-source components in their products. In October 2025, Microsoft began publishing VEX/CSAF documents—machine-readable statements that say “Product X contains Component Y” linked to CVEs. The program aims to replace vague security bulletins with deterministic, software-bill-of-materials (SBOM)–based attestations.

Azure Linux was an early target because it is a full, purpose-built distribution where Microsoft has deep visibility into the software supply chain. Other Microsoft products—especially those using Linux kernels as embedded components—take longer to inventory because build configurations and code inclusion vary. The phased rollout means we’ll see more attestations over time, but for now, Azure Linux is the only officially accounted-for product.

The bottom line

CVE-2024-35870 is a patched kernel flaw, but its impact on Microsoft’s ecosystem extends beyond Azure Linux. Until Microsoft completes its VEX rollout, administrators should assume nothing about the safety of WSL2, Marketplace images, or embedded Linux devices they get from the company. The advisory is a starting point, not the final word. Perform your own artifact inspections, apply patches where available, and keep an eye on MSRC for expanded attestations. In an era of shared open-source code, product-scoped attestations demand a product-scoped response.