CVE-2025-22111: Azure Linux isn't the only Microsoft kernel at risk

Title: CVE-2025-22111 — Is “Azure Linux” the only Microsoft product that ships the vulnerable code?
Short answer
No. Azure Linux is not the only Microsoft product that can include the vulnerable code (the affected part of the Linux kernel). Any Microsoft product or service that ships or operates a Linux kernel build — or relies on a host kernel you control in Azure — can be in scope and should be checked. Notably, Windows Subsystem for Linux (WSL/WSL2) ships a Microsoft-built Linux kernel; Azure virtual machine images and managed node images (including AKS node pools) run kernels supplied either by the distribution publisher or by Microsoft as “Azure‑tuned” kernels. You should treat those as potentially affected until you confirm the kernel version/build contains the fix. Why (brief technical recap)
CVE‑2025‑22111 is a Linux‑kernel vulnerability in the network (net) code — specifically the code paths handling SIOCBRADDIF and SIOCBRDELIF ioctls for bridge management. The root cause is an unnecessary RTNL lock/unlock sequence (the “RTNL dance”) that creates a race and can lead to a deadlock or denial‑of‑service under RTNL pressure. This is a kernel bug (not a separate userland library), so any product that ships or runs the Linux kernel binary is the surface to check. What “includes the open‑source library” actually means here

• The CVE is in the Linux kernel source tree — the net/bridge/ ioctl code — not in a standalone third‑party userland library. So the relevant question is: which Microsoft product ships or manages a Linux kernel binary that contains that code?
• If a Microsoft product ships a Linux kernel build or offers a managed Linux image (with a kernel binary), that product either includes or depends on the affected code and therefore must be assessed. If it only ships userland packages and relies on the host kernel (for example, a container image), it does not "include" the kernel code but it can be impacted indirectly by a vulnerable host kernel.

Microsoft products/services to check (concrete list and why)

• Azure Linux (Azure’s own kernel builds / “azl” / linux-azure)
• Microsoft publishes and maintains Azure‑tuned kernel builds (often packaged as linux-azure or “azl*” kernels for Azure images). If MSRC/your distro lists Azure Linux as a product component for a CVE, that product should be considered in scope. Many Linux distributions publish separate “linux‑azure” kernels for VMs running on Azure and Microsoft helps deliver and tune those kernels.
• Windows Subsystem for Linux (WSL / WSL2)
• WSL2 ships a Microsoft‑built Linux kernel (the microsoft/WSL2-Linux-Kernel source). Microsoft distributes kernel binaries for WSL and publishes the source; WSL’s kernel receives updates independently of the Windows release cadence. If that WSL kernel version lacks the fix, WSL will be affected on systems running it. Check your WSL kernel version and update using Microsoft’s WSL update flow.
• Azure virtual machines, managed images and AKS nodes
• Azure Marketplace images, platform images, and Azure‑tuned kernels are used for VMs and for managed Kubernetes node pools (AKS). Some of those images use distro vendor kernels, while others use Azure‑tuned kernels delivered for Azure. If your VM image or AKS node pool uses a kernel version that predates the patch for CVE‑2025‑22111, the system is potentially vulnerable/affected. Azure’s documentation describes the different image sources and the Azure‑tuned kernel concept.
• Any Microsoft distribution or appliance that bundles a Linux kernel
• In short: any Microsoft product that bundles or ships a compiled Linux kernel — or provides a kernel inside a VM image or appliance — must be checked. Microsoft’s security guidance (MSRC / CSAF/VEX) will list products that Microsoft determines are affected; until then, assume kernels shipped by Microsoft products are candidates for assessment. (Microsoft said they publish CSAF/VEX and will update CVEs if more products are impacted — see your MSRC quote.

Products that are generally NOT directly “including the library” but still need attention

• Microsoft container images and application packages (for example, .NET container images) do not include the kernel binary; they run on a host kernel. A vulnerable host kernel (for example, an Azure VM or local hypervisor that has the vulnerable kernel) can still expose an environment-wide risk. Microsoft’s guidance about container image rebuilds and base images explains you must pay attention to the host and base image.

How to determine whether a given Microsoft product/instance in your environment is affected

• Identify the kernel in use
• On each Linux system (Azure VM, AKS node, WSL2 instance, etc., run:
• uname -r (to get the kernel release string)
• cat /proc/version (to see vendor/build info)
• For WSL2, run wsl --status and uname -r inside a WSL shell to see the WSL kernel build. WSL has an explicit update/install mechanism (wsl --update).
• Map the kernel to known fixed versions or distro advisories
• Consult the CVE/NVD/OSV entries for the vulnerability (they list affected software and references), and consult your distribution vendor security advisories and Microsoft’s MSRC guidance. Distributors (Ubuntu, RHEL, SUSE, etc. will say whether their package is fixed and what package/version to install. Microsoft’s Azure images and WSL kernel releases likewise have published version strings you can check.
• If you run WSL2, check and update the WSL kernel
• Update WSL kernel: open an elevated PowerShell and run:
• wsl --update
• wsl --shutdown
• Then restart your WSL instances and verify uname -r. Microsoft documents WSL kernel updates and the wsl --update flow.
• If you run Azure VMs / AKS node pools
• For IaaS (VMs) running vendor images: apply the distro’s kernel/security updates (apt/yum/zypper) and reboot. For Azure‑tuned kernels, use the image update path provided by the publisher or Microsoft (Azure Marketplace image updates, vm image gallery updates). Azure’s guidance describes marketplace/platform images and Azure‑tuned kernels. If node images are managed (AKS), follow the AKS node upgrade path to move node pools to patched images.
• If you run custom images or on‑prem Microsoft products that embed Linux
• Open a support ticket and confirm whether the vendor‑supplied kernel has the patch, or replace the kernel with a patched build if feasible. If Microsoft ships the kernel for that product (e.g., WSL kernel), check Microsoft update channels (MS Update / WSL update / MSRC advisory).

Practical mitigation steps (priority list)

• Inventory first (highest priority)
• Inventory all places you run Linux kernels that Microsoft ships or manages: Azure VMs, AKS node pools, WSL2 endpoints, and any Microsoft images (MCR) you run.
• Inventory kernel versions and compare them against vendor/MSRC/OSV/NVD information about which versions are patched. Use “uname -r” and vendor package versions to map quickly.
• Patch/upgrade kernels and reboot where required
• Apply official distro patches (apt/yum/zypper) for the kernel package and reboot the host.
• For WSL2: run wsl --update (PowerShell admin) then wsl --shutdown and restart WSL instances.
• For managed services
• AKS: upgrade node pools so that nodes run an image/kernel that contains the fix.
• Azure Marketplace images: ensure marketplace images are updated to the latest patched SKU or apply in‑place kernel updates and reboot.
• If you cannot patch immediately, apply risk‑mitigations
• Limit administrative access to network bridge configuration (CAP_NET_ADMIN).
• Restrict who can perform the affected ioctl operations, and limit untrusted workloads from creating the race scenarios (network bridging operations).
• Monitor for symptoms of deadlock/RTNL pressure (kernel logs, systemd journal, dmesg). The vulnerability manifests as RTNL contention leading to hangs/DOS.
• Monitor vendor advisories and MSRC
• Microsoft publishes CSAF/VEX advisories (MSRC) and will update CVEs if additional Microsoft products are impacted; monitor MSRC and vendor security advisories for product‑specific remediation guidance. (You cited MSRC’s statement about publishing CSAF/VEX and updating the CVE if more products are impacted.

How to validate the fix (examples)

• On a patched host, the kernel version reported by uname -r should correspond to the patched package or to a kernel release the distro/MSRC lists as fixed.
• Vendors commonly include the CVE identifier in the package changelog or advisory; confirm the package update notes mention CVE‑2025‑22111 or the upstream commit that fixed it.
• For WSL, confirm WSL kernel binary is at the patched tag/release published by microsoft/WSL2-Linux-Kernel and that wsl --update reports up‑to‑date.

What to tell customers and teams (recommended communication)

• If you’re responsible for Azure virtual machines or AKS: treat this as a kernel update; schedule kernel updates and reboots for affected VMs/pools. If you use marketplace images, check the Marketplace image publisher’s advisory and update the image SKU if Microsoft or the distro provider has published a patched image.
• If you are a Windows desktop/laptop user running WSL2: run wsl --update and reboot WSL. Verify the kernel version inside WSL (uname -r).
• If you run containers on Azure VMs or managed hosts: patch the host kernel first. Containers do not include the kernel; they inherit the host kernel’s security posture.

References and authoritative sources (used in this article)

• NVD entry for CVE‑2025‑22111 (detailed CVE description).
• OSV entry for CVE‑2025‑22111 (upstream vulnerability summary and references).
• Microsoft / WSL documentation and WSL kernel source (Microsoft ships a Linux kernel for WSL2). If you run WSL2, update it via the documented flow.
• Azure documentation on Linux images and Azure‑tuned kernels (explains marketplace/platform images and that Azure uses tuned kernels for cloud workloads). This is relevant because Azure images can include a kernel that Microsoft helps deliver/update.
• Example distro advisory referencing linux‑azure (Ubuntu linux-azure updates)—illustrates how Azure‑tuned kernels are published and updated by distro/azure channels.

Final, plain‑language answer to your question
No. Azure Linux is an important Microsoft product that packages a Linux kernel and therefore is obvious to check, but it is not the only Microsoft product that can include the vulnerable kernel code. WSL2 (the Windows Subsystem for Linux) ships a Microsoft‑built Linux kernel; Azure VM images and AKS nodes run kernels (either vendor kernels or Azure‑tuned kernels). All of these are places where the Linux kernel code for net/bridge/ioctl can live — so they should be inventoried and checked. Microsoft’s MSRC statement that “if impact to additional products is identified, we will update the CVE” is consistent with this: the CVE is about upstream kernel code; Microsoft will list product impact for Microsoft‑shipped kernels/products as they finish their investigation and VEX/CSAF disclosures. If you want, I can:

• Help you build a short audit checklist and commands to inventory kernel versions across a fleet of Azure VMs, AKS node pools and WSL endpoints.
• Produce step‑by‑step remediation playbooks (for WSL, for Ubuntu/Azure images, for RHEL/SLES on Azure, and for AKS node upgrades).
• Watch MSRC and distro advisories and send you a short update summary when Microsoft or major distro vendors publish product‑specific VEX/patch notes.

Which of those would you like me to prepare next?

---

Source: MSRC Security Update Guide - Microsoft Security Response Center