Microsoft has officially confirmed that Azure Linux is affected by CVE-2024-44974, a use-after-free bug in the Linux kernel’s Multipath TCP (MPTCP) subsystem, and began publishing machine-readable security advisories to speed remediation. But the software giant’s carefully worded disclosure leaves open the possibility that other Microsoft-maintained Linux images—including those used in WSL, virtual machines, and Marketplace appliances—also carry the vulnerable code. Security teams running any Microsoft Linux artifact should act now to verify their exposure.

The vulnerability at a glance

CVE-2024-44974, published in September 2024, targets a race condition in the MPTCP path manager. Two functions, select_local_address() and select_signal_address(), select an endpoint entry while under RCU protection but later reference that entry after the RCU read lock is released. If the entry is freed in the interim, those stale references become use-after-free hazards—a classic RCU lifetime mistake. Upstream kernel maintainers stamped out the bug by copying the necessary endpoint fields while still inside the RCU section, eliminating the dangling pointer.

MPTCP itself is an evolution of TCP that lets a single connection use multiple network paths simultaneously, improving resilience and throughput. It lives in the kernel as an upper-layer protocol and can be compiled in via CONFIG_MPTCP. Even when compiled, it may be disabled at runtime through sysctls like net.mptcp.enabled. This dual dependency—build-time configuration and runtime flags—means two systems running similar kernel versions can differ in whether they are actually exploitable.

Microsoft’s Security Response Center (MSRC) released an advisory stating that “Azure Linux includes this open-source library and is therefore potentially affected.” The advisory also notes that the company began publishing CSAF/VEX data in October 2025 and will update the CVE if additional products are found to be impacted. That language is a direct answer to the question on the advisory page: “Is Azure Linux the only Microsoft product that includes this open-source library and is therefore potentially affected by this vulnerability?” The answer, in essence, is “not necessarily.”

Who’s affected: a breakdown

Azure Linux customers are the only ones with a definitive, public attestation from Microsoft. If you run Azure Linux images, treat this as a confirmed, high-priority patch scenario. The distro’s kernel packages will have the upstream fix integrated in their update streams.

Windows Subsystem for Linux (WSL) users run a Microsoft-built kernel that may or may not contain the vulnerable commit range. Microsoft has not yet attested whether WSL kernels are affected. Because WSL kernels are separate artifacts with their own versioning and configuration, you cannot assume they are safe just because they aren’t named in the advisory. Check your WSL kernel version (via uname -r inside the WSL instance) and compare it to known patched versions.

Azure VM images and Marketplace appliances often ship with Microsoft-curated kernels, such as the linux-azure kernel used by some VM SKUs. These are distinct artifacts from the Azure Linux distro. Again, no attestation yet means you must inventory them individually. The same goes for any CBL-Mariner derivatives or custom images built from Microsoft’s base images.

Non-Microsoft Linux distributions running on Azure or on-premises are covered by their own vendor advisories. Ubuntu, Red Hat, SUSE, Debian, and Amazon Linux have all issued patches for this CVE. Follow your distro’s guidance.

The key operational takeaway: Microsoft’s attestation is an authoritative “affected” stamp for Azure Linux, but the absence of mention for other products is not proof of immunity. Security teams must treat their wider Microsoft Linux footprint as potentially vulnerable until verified.

Why this bug matters

Use-after-free flaws in kernel networking code are always serious. At minimum, they can cause kernel crashes (oopses) and denial of service. In skilled hands, they can be escalated to local privilege escalation or even arbitrary code execution. While most assessments classify CVE-2024-44974 as a local attack vector—meaning an attacker needs some level of access to the target system—the risk is amplified in cloud and multi-tenant environments. A compromised container or a malicious workload on a shared host could trigger the bug to break out of isolation.

Moreover, MPTCP is not yet ubiquitous, but it is growing in relevance. It underpins features like Wi-Fi/cellular handover on mobile devices and is being adopted in cloud scenarios where multiple network paths (e.g., multiple NICs or VPN links) can boost reliability. If you haven’t intentionally enabled MPTCP, you might still have it active in your kernel by default, depending on your distro and configuration. That’s why checking runtime settings is essential.

How we got here

Microsoft’s relationship with open-source code has deepened enormously over the past decade. Azure Linux (formerly CBL-Mariner) is its in-house Linux distribution, optimized for Azure and internal services. WSL brought a full Linux kernel to Windows. Countless Azure services run on Linux under the hood. With that footprint comes the responsibility to track and patch upstream vulnerabilities just as diligently as any other Linux vendor.

The MSRC advisory for CVE-2024-44974 is part of a broader shift toward transparency. In October 2025, Microsoft began publishing machine-readable CSAF and VEX documents, which provide standardized vulnerability status information per product. This move mirrors what other major Linux vendors have done and helps automate the triage process for security operations centers (SOCs). But the rollout is incremental: Microsoft is attesting products as it inventories them. That means there will be a window where some Microsoft Linux artifacts have been assessed and others have not. For a vulnerability like CVE-2024-44974 that touches a specific kernel subsystem, that inventory process is especially nuanced because it depends on exact kernel commit history, backported patches, and compile-time options.

Immediate steps to secure your systems

Don’t wait for an all-clear from Microsoft that may never arrive for your specific image. Start your own verification now. Here’s a prioritized checklist:

  1. Patch Azure Linux systems first. If you manage any Azure Linux instances, apply Microsoft’s recommended kernel updates immediately. These are the only systems with a clear, public “affected” status.

  2. Inventory every Microsoft-maintained Linux kernel you run. Gather a list of: WSL installations, Azure VM instances using linux-azure or other Microsoft-provided kernels, Marketplace images from Microsoft, and any custom builds derived from Microsoft base images. For each, record the kernel version with uname -r.

  3. Check whether the vulnerable code could be active. For each host:
    - Verify if MPTCP is compiled in: look for CONFIG_MPTCP in /proc/config.gz or /boot/config-$(uname -r). If absent, the kernel is not vulnerable at the build level.
    - Check runtime enablement: sysctl net.mptcp.enabled. A value of 1 means MPTCP is live; 0 means disabled.
    - Look for active MPTCP sockets with ss --mptcp. No output suggests no current MPTCP connections.

  4. Mitigate if you can’t patch immediately. If a system must stay up and you confirm MPTCP is compiled in and enabled, disable it at runtime: sudo sysctl -w net.mptcp.enabled=0. This removes the attack surface until you can reboot into a patched kernel. Note that this is a temporary workaround, not a replacement for a kernel update.

  5. Monitor for suspicious activity. SOC teams should watch for kernel oops messages containing “mptcp” or the vulnerable function names. Unexpected MPTCP connections on hosts that shouldn’t be using them are a red flag.

  6. Automate going forward. Ingest Microsoft’s CSAF/VEX feeds into your vulnerability management platform once they are available. Use image scanning tools that can detect kernel configurations and backport statuses, not just version strings. This will catch future cases where a vendor attestation hasn’t yet landed for your specific artifact.

The long view: Microsoft’s evolving security practices

CVE-2024-44974 is a textbook example of why cloud customers can’t afford to take vendor advisories at face value when they run multiple flavors of Linux from a single provider. Microsoft’s move toward structured, machine-readable attestations is a welcome improvement, but it’s not a silver bullet. Until its entire Linux inventory is mapped, the responsibility for verification sits with the operators.

Expect Microsoft to expand its CSAF/VEX coverage steadily. If your organization uses a mix of Microsoft and third-party Linux images, now is the time to incorporate artifact-level attestation into your patch management workflows. The days of trusting that a missing advisory equals safety are over. For CVE-2024-44974, start patching Azure Linux today, then work through the rest of your images methodically. The kernel fix is small, well understood, and already upstreamed—so the faster you deploy it, the sooner you close a gap that attackers might already be probing.