CVE-2024-44974: MPTCP UaF in Linux Kernel and Azure Linux Attestation

CVE-2024-44974 is a Linux‑kernel Multipath TCP (MPTCP) use‑after‑free (UaF) defect in the MPTCP path manager that was fixed upstream in 2024 — and Microsoft’s public advisory language naming Azure Linux as a product that “includes this open‑source library and is therefore potentially affected” is an authoritative, product‑level attestation for Azure Linux but not a technical guarantee that no other Microsoft artifact could ship the same vulnerable code.

---

Background / Overview​

CVE‑2024‑44974 was published in September 2024 and describes a race / lifetime bug in the MPTCP path manager: two functions, select_local_address() and select_signal_address(), select an endpoint entry while under RCU protection but return a reference that may be accessed later — after the RCU read‑lock has been released — creating a use‑after‑free window. The upstream fix is straightforward: copy the needed endpoint information while still inside the RCU section so later references do not dereference freed memory.
MPTCP is an evolution of TCP that enables a single connection to use multiple network paths; it lives in the kernel as an upper‑layer protocol and can be compiled into kernels (CONFIG_MPTCP) or exposed/disabled at runtime via sysctls such as net.mptcp.enabled. Whether a given server or image is vulnerable therefore depends on three artifact‑level properties: the kernel version/commit set, the kernel configuration (is MPTCP compiled in or available), and runtime settings (is MPTCP enabled).
Practical evidence of the CVE’s existence and distribution can be found across multiple vendor advisories and vulnerability databases (NVD, OSV, Debian, SUSE, AWS ALAS, Ubuntu advisories) — confirming the kernel‑level origin of the defect and the fact that multiple Linux distributions issued patches or updated kernels to incorporate the upstream fix.

---

What Microsoft actually said — and what that wording means​

When Microsoft’s Security Response Center (MSRC) writes a line like “Azure Linux includes this open‑source library and is therefore potentially affected by this vulnerability,” it is doing two related but distinct things:

• It is declaring the results of an inventory check: Microsoft has inspected Azure Linux artifacts (kernels, packages and images) and found the upstream component implicated by the CVE. That makes Azure Linux an authoritative, in‑scope product for remediation and priority patching.
• It is not implicitly saying “no other Microsoft product ships this code.” The wording is deliberately scoped to a product family rather than asserting exclusivity across Microsoft’s entire portfolio; Microsoft has also published that it will expand machine‑readable CSAF/VEX attestations (a rollout that began in October 2025) and update CVE mappings if additional Microsoft products are identified as carriers of the upstream code.

In short: the MSRC statement is an attestation — a reliable signal that Azure Linux customers must act on immediately — but absence of attestations for other Microsoft products is not proof that those products are unaffected. That is a crucial operational distinction. Multiple independent analyses and community explanations have emphasized exactly this point.

---

Short, practical answer to the core question​

Is Azure Linux the only Microsoft product that includes the open‑source MPTCP code and is therefore potentially affected by CVE‑2024‑44974?

• Short answer: No — not necessarily.
  Azure Linux is the only Microsoft product Microsoft has publicly attested (so far) to include the implicated upstream component for this CVE. That attestation is authoritative for Azure Linux and requires immediate remediation for Azure Linux customers. However, other Microsoft‑distributed Linux artifacts (for example, WSL kernel builds, linux‑azure kernels used in some VM SKUs, CBL‑Mariner‑derived images, Marketplace appliances, and any Microsoft images or appliances that include a Linux kernel) are plausible carriers until they are individually inventoried and attested.
• Operational meaning: treat Microsoft’s Azure Linux statement as a high‑priority remediation signal for Azure Linux images, and perform artifact‑level verification (SBOMs, kernel version checks, config inspection) for any other Microsoft images you run. Microsoft has committed to updating VEX/CSAF records when it finds additional affected products — but don’t wait for that to start your own inventory work.

---

Why “product‑scoped attestation” is not an exclusivity guarantee​

There are several technical reasons the MSRC wording is intentionally scoped:

• Kernel components are artifact properties. Whether a binary includes an upstream driver or feature depends on the exact set of upstream commits, local backports, and kernel build-time configuration (CONFIG_* flags). Two Microsoft images built from different kernel trees or with different compile‑time options can therefore differ in whether they carry the vulnerable code.
• Microsoft ships multiple kernel artifacts. Microsoft produces and distributes a variety of kernels and images: Azure Linux (the Microsoft distro family), linux‑azure kernels used for some VM SKUs, WSL2 kernels shipped to end users, CBL‑Mariner derivatives, Marketplace VM images, and more. Each artifact must be inventoried individually; a declaration for one product family does not automatically apply to all. Community investigations and vendor FAQs repeatedly point this out.
• The vulnerability’s presence depends on runtime configuration. Even if the kernel binary includes MPTCP code, a system might have MPTCP disabled at runtime (sysctl net.mptcp.enabled=0) or the relevant socket API may be unavailable; conversely, a kernel compiled without MPTCP is not vulnerable even if the distribution packages include the source files. This variability makes per‑artifact verification necessary.

Those technical realities explain why Microsoft’s approach — publish precise, machine‑readable VEX/CSAF attestations as inventories complete — is both practical and conservative, but also why customers must not assume “no mention = safe.”

---

Impact and exploitability — what defenders need to know​

• The defect is a memory‑safety bug (use‑after‑free) in kernel networking code, which can cause kernel undefined behavior, crashes (OOPS), or potentially privilege escalation or code execution in extreme scenarios. Upstream advisories and vendor tracking label the issue as a kernel‑level memory corruption risk.
• Attack vector: the majority of published assessments treat the bug as local in nature (attacker needs local access or the ability to trigger kernel code paths that operate on endpoint entries), which lowers the likelihood of trivial remote exploitation on a default remote‑only service. However, in cloud or multi‑tenant environments a lateral attacker with access to a VM/container or a poisoned tenant workload could trigger the defect. This is why cloud customers and multi‑tenant hosts should treat kernel networking bugs seriously even when CVSS indicates local attack vectors.
• Vendor scoring variance: different vendors sometimes publish different CVSS scores and severity assessments for the same kernel defect (e.g., NVD vs. SUSE vs. Amazon Linux). That reflects differences in threat modeling (impact vs. attack surface). Operators should use the vendor guidance that applies to the images and kernels they run — but apply defense‑in‑depth where kernel networking code is reachable by untrusted workloads.

---

How to check whether your Microsoft artifacts are affected (practical checklist)​

The following steps are prioritized for speed and accuracy. Adopt them across any Microsoft images you operate (Azure VM images, Marketplace appliances, WSL kernels, AKS node images, etc.):

• Inventory: produce a list of all Microsoft‑supplied Linux artifacts in use (Azure Linux images, linux‑azure kernels used for VM SKUs, WSL kernels, Marketplace images, CBL‑Mariner‑derived images). This is the only way to turn “absence of attestation” into a verifiable state.
• Identify kernel version and build: on each host or image, run:
• uname -r
• rpm -q --queryformat '%{VERSION}-%{RELEASE}\n' kernel (RHEL/Azure)
• dpkg -l linux-image-* (Debian/Ubuntu)
  Record the kernel version and compare to upstream and vendor advisory lists for the CVE. Many distribution advisories list patched kernel versions (see Ubuntu/ALAS/other advisories).
• Check whether MPTCP is compiled and enabled:
• Runtime enablement: sysctl net.mptcp.enabled (value 1 = enabled).
• ULP availability: sysctl net.ipv4.tcp_available_ulp (look for “mptcp”).
• Active MPTCP sockets: ss --mptcp (shows active MPTCP connections and subflows).
• Check kernel config (artifact inspection):
• If you have the kernel config (often at /proc/config.gz or in /boot/config-$(uname -r)), search for CONFIG_MPTCP, CONFIG_MPTCP_IPV6, and related flags. If CONFIG_MPTCP is not set, the kernel lacks MPTCP at build time.
• For WSL / Marketplace images:
• WSL ships a Microsoft‑built kernel binary; check the kernel version inside WSL (uname -r) and compare it to MSRC VEX/CSAF attestations and upstream patches. Treat WSL kernels as separate artifacts and verify them individually. Community analyses emphasize this need for artifact‑level verification.
• If you cannot patch immediately: consider short‑term mitigations:
• Disable MPTCP at runtime: sudo sysctl -w net.mptcp.enabled=0 (effective until next boot or sysctl restore). This removes runtime exposure for kernels that include MPTCP code but have it disabled. Note: this is a mitigation, not a replacement for upstream kernel patches.
• For images under your control, rebuild kernels without MPTCP or apply vendor backports promptly and schedule reboots as required.

---

Remediation priorities and an operational playbook​

• Azure Linux images: treat them as confirmed, attested carriers and apply Microsoft’s recommended updates for the product immediately. MSRC’s attestation is the canonical guidance for Azure Linux customers.
• All Microsoft‑provided kernels (WSL kernels, linux‑azure, Marketplace images): run the artifact checklist above. Do not assume these are safe simply because they are not named in the MSRC line. If a kernel contains the vulnerable commit range and MPTCP is enabled or in use, schedule patching. Community writeups repeatedly advise treating MSRC’s language as product‑scoped, not global.
• Non‑Microsoft kernels (third‑party distros on Azure): follow vendor guidance (Ubuntu, RHEL, Debian, SUSE, Amazon Linux) and apply patches as published — many distros published advisories mapping CVE‑2024‑44974 into their stable branch updates.
• Automation:
• Ingest Microsoft’s CSAF/VEX feeds (MSRC announced a VEX rollout beginning Oct 2025) and automate matching to your inventory where possible. This reduces manual triage load and ensures you receive product‑scoped attestations as Microsoft expands coverage.
• Use image scanning tools and SBOM ingestion to detect versions of kernels or packages that include MPTCP code or specific upstream commit ranges.
• Post‑patch verification:
• After applying vendor updates and reboots, validate that sysctl net.mptcp.enabled is as expected, that kernel versions match vendor‑issued patched versions, and that no regression or unintended behavior has been introduced.

---

Strengths and limitations of Microsoft’s attestation approach​

Strengths

• Actionable clarity for Azure Linux customers. Microsoft’s explicit attestation provides a clear signal so customers running Azure Linux can immediately prioritize updates. That single‑product focus accelerates defensive action where Microsoft can provide end‑to‑end confirmation (image → kernel → package mapping).
• Machine‑readable rollout (CSAF/VEX). By publishing CSAF and VEX outputs, Microsoft enables automation and reduces the noisy manual triage that many security teams face when a high volume of CVEs arrive. The VEX standard supports precise “Not Affected / Under Investigation / Known Affected / Fixed” statuses per product.

Limitations / Risks

• Inventory coverage lag. Microsoft’s phased approach means there is a window where only a subset of Microsoft products have been inventoried and attested. Security teams that operate diverse Microsoft images must perform their own artifact checks rather than rely solely on absence of attestations. Multiple community posts highlight this operational caveat.
• Artifact heterogeneity. Microsoft distributes many different kernel artifacts; a product‑level attestation does not automatically propagate to all images and kernels. This fragmentation shifts the burden to customers to verify each artifact they run.
• Potential for misinterpretation. Casual readers might conclude “Azure Linux is affected — others are not” simply because MSRC named Azure Linux. That misreading is risky and has been the basis for community clarifications in forum threads and advisories.

---

Technical deep dive (brief): why the MPTCP path manager bug matters​

The MPTCP implementation separates path management from packet scheduling. The path manager maintains lists of available endpoints (addresses) for subflows. The bug arises when the code returns a pointer or reference to an entry selected under RCU protection and then uses that reference later, outside the RCU read‑critical section; if the entry is freed in the interim, later dereferences become UaF events. The upstream fix copies the necessary endpoint fields while still under RCU protection — a small but effective change that eliminates the deferred pointer usage. This is a classical RCU lifetime mistake and the fix pattern is well understood by kernel maintainers.
From an exploitability perspective, constructing a chain that turns an UaF into arbitrary code execution in the kernel is nontrivial and usually requires additional conditions (predictable heap, controlled allocations, etc.). But kernel UaFs remain high‑value for local attackers and can destabilize systems — therefore, organizations must treat them as high priority for patching in multi‑tenant or exposed environments.

---

Detection guidance for SOCs and incident responders​

• Watch for kernel OOPSes and panic logs that mention MPTCP, mptcp, select_local_address, or path‑manager functions. Vendor patches and upstream commits often use similar function names; search logs accordingly.
• Use runtime telemetry to detect unexpected MPTCP socket creation on hosts that should not be using MPTCP: ss --mptcp and netstat/ss outputs can show MPTCP subflows. Unexpected usage on multi‑tenant hosts is a red flag.
• Image scanning: include kernel packages and kernel config artifacts in your CI/CD image scans and SBOM generation so that CVE mapping can be automated against your image inventory.

---

Conclusion — practical, risk‑based posture​

Microsoft’s statement that “Azure Linux includes this open‑source library and is therefore potentially affected” is accurate and operationally useful: if you run Azure Linux images you must act immediately and follow Microsoft’s remediation guidance. However, that MSRC phrasing is an inventory attestation for a single product family — not a technical exclusivity guarantee. Any Microsoft image or artifact that ships a Linux kernel build containing the vulnerable MPTCP commit range and has MPTCP available or enabled is a plausible carrier until verified.
Recommended action plan for administrators and security teams:

• Treat the Azure Linux attestation as high priority and apply Microsoft updates for Azure Linux immediately.
• Inventory every Microsoft‑distributed image and kernel you run (WSL, linux‑azure, Marketplace, CBL‑Mariner derivatives) and verify kernel version/config against vendor advisories.
• If immediate patching is not possible, mitigate by disabling MPTCP at runtime (sysctl -w net.mptcp.enabled=0) and increase monitoring for kernel OOPSes and abnormal MPTCP socket activity.
• Automate ingestion of Microsoft’s CSAF/VEX outputs and vendor advisories to reduce manual triage and ensure you receive updates as Microsoft expands product attestations.

Finally, consider this MSRC attestation language as the beginning of a discovery process — not the end. When large vendors inventory and publish attestations product‑by‑product, the immediate benefit is clear: deterministic guidance for the attested product. The remaining work — inventory, verification, and remediation across the rest of your estate — is the operational responsibility for defenders, and it has to begin now.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center