{
"title": "Microsoft Confirms Azure Linux Hit by Kernel Bug CVE-2024-44989, But WSL Status Still Unknown",
"content": "Microsoft has publicly confirmed that its Azure Linux distribution is potentially affected by CVE-2024-44989, a medium-severity kernel bug that can crash systems under certain networking conditions. But the advisory, updated earlier this month, leaves users of other Microsoft-supplied Linux kernels—including the Windows Subsystem for Linux (WSL) and the linux-azure kernel used in Azure virtual machines—without a clear answer on their own exposure. In a brief FAQ appended to the Security Update Guide entry, Microsoft says it has begun issuing machine-readable CSAF and VEX documents to improve transparency, and will update the CVE record “if impact to additional products is identified.” For now, Azure Linux is the only product name in scope.
What’s in Microsoft’s Advisory
The MSRC update for CVE-2024-44989 is short but significant. It directly addresses a question that many IT operators likely asked: “Is Azure Linux the only Microsoft product that includes this open-source library and is therefore potentially affected?” The response notes that Azure Linux’s commitment to keeping open-source components up to date is a “main benefit” to customers, and that Microsoft began publishing CSAF/VEX attestations in October 2025 to give customers machine-readable signals about which products carry which vulnerabilities.Crucially, the text adds that if other products are found to contain the vulnerable code, “we will update the CVE to reflect this.” This is not a blanket “no other product is affected” statement; it’s an inventory status report. Microsoft is telling the world that it has scanned Azure Linux and found the offending library present. It has not yet said the same about WSL kernels, Azure-tuned linux-azure packages, or any other kernel binaries it distributes. For defenders, that means drawing conclusions from silence would be a mistake.
The Vulnerability: A Race in the Bonding Driver
CVE-2024-44989 was disclosed in July 2024 and patched in the upstream Linux kernel shortly thereafter. It resides in the bonding driver, specifically in the IPsec/XFRM offload path. When a bonded network interface is reconfigured—say, a slave link is removed or fails—the driver can set an internal pointer (realdev) to NULL while packets are still being processed. If an offload callback tries to dereference that pointer during the window, the kernel oopses or panics. The result is a denial of service; an attacker with local access or the ability to trigger a bond reconfiguration can crash the system.The fix, merged in mainline and backported to stable kernel trees (5.10.y, 5.15.y, 6.1.y, 6.6.y, and others), refactors how xfrm offload state tracks the underlying device, eliminating the race. Most major Linux distributions shipped patched kernels months ago. NVD assigned the bug a CVSS v3.1 base score of 5.5 (Medium), with the vector highlighting availability impact and the requirement that an attacker have local, low-privilege access.
Why does this matter to Microsoft? Because the vulnerable code is part of the kernel source tree, and any kernel built from an affected revision—with the CONFIG
BONDING option enabled—will carry the defect. Microsoft’s products include several Linux kernel artifacts, and while Azure Linux was the first to be attested, others may be built from similar source snapshots.What It Means for You
Depending on how you consume Microsoft’s Linux platforms, the impact varies.For Azure Linux Users
You have the clearest path. Microsoft has explicitly stated that Azure Linux images include the affected library and are “potentially affected.” This isn’t a conditional warning—it’s a confirmation that the vulnerable code exists in the default Azure Linux kernels. If you run Azure Linux VMs or container instances, check your running kernel version and apply the latest available updates immediately. Microsoft’s CSAF/VEX documents will specify which Azure Linux kernel versions contain the fix; refer to those for exact package names and release numbers.For WSL2 and Azure VM Users
This is where the fog thickens. WSL2 ships a custom Linux kernel that is distributed through Windows Update and built from the mainline stable tree. Historically, WSL kernels have kept pace with LTS branches; recent WSL kernel versions (e.g., 5.15.153.1) are based on 5.15.y, which falls within the patch window for CVE-2024-44989. The kernel’s configuration often includes the bonding driver as a module (CONFIGBONDING=m). If that module is present—even if not loaded—the vulnerable code is on disk.Azure virtual machines can run either the linux-azure tuned kernel (provided by Microsoft and updated through the distro’s package manager) or a standard distribution kernel. The linux-azure kernel, like the WSL kernel, is a fork of an upstream stable branch with Azure-specific optimizations. Its build configuration may differ from Azure Linux’s, but it’s generally based on the same upstream source. At this time, Microsoft has not issued a VEX attestation for the linux-azure or WSL kernels, meaning the company hasn’t formally declared them affected or not affected.
Practically, this means you can’t rely on official word. You’ll need to check for yourself.
For Marketplace and Third-Party Images
Many Azure Marketplace images come from Canonical, Red Hat, SUSE, and other ISVs. Microsoft’s Azure Linux attestation doesn’t cover those images; they remain the responsibility of their publishers. Similarly, appliances and containers that bundle a Linux kernel—even if labeled “Microsoft” or “Azure”—might be built on a third-party base. Check your image’s origin: if it’s from a vendor, consult that vendor’s advisory. If it’s a Microsoft-maintained base image (like Mariner, which underpins Azure Linux), the Azure Linux attestation likely applies.How We Got Here: The Transparency Push
Microsoft’s move to publish CSAF (Common Security Advisory Framework) and VEX (Vulnerability Exploitability eXchange) documents is part of a broader industry shift toward machine-readable security advisories. Announced in October 2025, the program aims to give customers structured data about which products are affected by a CVE, sparing them from hunting through long PDFs or text pages. Azure Linux was the logical first product because it’s a distribution Microsoft builds and manages end to end.For CVE-2024-44989, the MSRC team apparently ran an internal scan on Azure Linux source trees and found a match to the upstream commit range. Because the advisory system is new, however, not all Microsoft products have been mapped. The FAQ implies that other products will be assessed as the CSAF/VEX initiative expands. In the meantime, customers must fill the gap with their own vetting.
This incident also highlights a tension in how Microsoft handles its growing Linux footprint. The company maintains several distinct kernels—Azure Linux kernel, WSL kernel, Hyper-V/Azure guest kernels, and possibly kernels for IoT or edge appliances. Each is built from a different upstream baseline and configuration. Tracking vulnerabilities across this fragmented ecosystem is more complex than with Windows, where a single kernel version dominates. The CSAF/VEX approach is meant to simplify that, but until the database is fully populated, operators are left to piece things together.
What to Do Now
Here’s a prioritized checklist for administrators and developers running Microsoft-supplied Linux environments.Immediate Actions
Patch Azure Linux immediately. Check the MSRC CVE page or your Azure Linux update channel for kernel updates that address CVE-2024-44989. Azure Linux 2.0 and 3.0 base images should have updates available. Apply them through your normal package management (tdnf, apt, or the Azure-hosted package feed). Update WSL kernels. If you use WSL2 on Windows 10/11, runwsl --update from PowerShell or Command Prompt to ensure you have the latest kernel. As of this writing, the latest stable WSL kernel version is 5.15.153.1-2; later versions may incorporate the patch. Verify by running uname -r inside your WSL distro. If the kernel version is older than 5.15.154 (approximately), you may still be vulnerable. Note: WSL kernel updates are delivered through Windows Update; if auto-update is off, manually trigger it.
Update linux-azure kernels on Azure VMs. For VMs running the linux-azure kernel, use the distribution’s package manager (e.g., apt for Ubuntu, yum for RHEL/CentOS) to install the latest kernel package. Check the changelog for references to CVE-2024-44989 or the patch series “net: bonding: fix xfrm realdev null pointer dereference.”
Verification Steps
Don’t guess—verify. On every Linux instance you manage, run these commands:- Check kernel version:
uname -r. Compare to the NVD affected version ranges (roughly kernels 5.10 through 6.1 before the patch dates). - Check if bonding module is present:
modinfo bondingorlsmod | grep bonding. If the module exists (even if not loaded), the kernel contains the vulnerable code if the build source was unpatched. - Inspect kernel config:
zgrep CONFIG_BONDING /proc/config.gz. If it returns “y” or “m”, the bonding driver is compiled in. - Look for active offload:
ip xfrm statewill list IPsec states. If you use IPsec offload on bonded interfaces, you’re worth patching urgently.
Mitigation if Patching Is Delayed
If you cannot update immediately, reduce the attack surface:- Disable IPsec offload on bonded interfaces if it’s not essential. This can be done by removing the “offload” flag from the XFRM policy or by avoiding bonding topology changes.
- If you don’t need bonding, unload the bonding module (
rmmod bonding). However, note that a re-configuration event could still panic the kernel if the module is loaded later; removing it prevents accidental touch. - Monitor logs for kernel oops or panic messages containing “bond” and “xfrm”. Unplanned reboots might signal that the bug was triggered.