CVE-2024-45009: MPTCP Kernel Bug and Azure Linux Attestation

The Linux kernel bug tracked as CVE-2024-45009 is a medium‑severity defect in the kernel’s Multipath TCP (MPTCP) path manager that can lead to incorrect counter handling during subflow removal. Microsoft’s public advisory language names Azure Linux as a product that “includes this open‑source library and is therefore potentially affected,” but that narrow phrasing reflects a product‑scoped attestation rather than a universal census of every Microsoft artifact. In practical terms: Azure Linux is the confirmed Microsoft product for which Microsoft has completed inventory and attested inclusion, but other Microsoft‑distributed Linux artifacts — including some kernel builds and VM or marketplace images — could also carry the same vulnerable upstream code depending on kernel version and build configuration.

Background / Overview​

CVE-2024-45009 was disclosed as a bug in the Linux kernel’s MPTCP implementation that affects the path manager’s handling of the add_addr_accepted counter when processing RM_ADDR (remove address) and related subflow events. The net effect is a logic error where the counter may be decremented in situations where it should not be, a condition discovered partly through selftests and KASAN instrumentation during kernel testing. The issue has a CVSSv3 base score in the medium range and has been addressed in upstream kernel trees and in vendor kernel updates.
MPTCP is an extension of TCP that allows a single transport session to use multiple network paths simultaneously. It’s used in specialized networking scenarios (mobile aggregation, redundancy, multipath links in datacenter networks) and is included in mainline kernels when the feature is enabled at build time. Whether a given binary kernel image is vulnerable therefore depends on three independent factors:

• whether the kernel version includes the upstream commit range with the vulnerable code,
• whether the kernel was built with MPTCP enabled (CONFIG_MPTCP), and
• whether the vendor has backported the patch into their kernel packages or shipped an updated kernel.

---

What Microsoft actually said — and how to read it​

Microsoft’s public advisory language for a number of Linux CVEs introduced during its VEX/CSAF rollout contains a specific FAQ-style paragraph: Microsoft confirmed that Azure Linux includes the implicated upstream component and therefore Azure Linux is “potentially affected,” and Microsoft committed to expand VEX/CSAF attestations if additional Microsoft products are later found to include the same open‑source component. That message is accurate and actionable for Azure Linux customers: Microsoft has completed inventory work for that product family and published machine‑readable attestations (VEX/CSAF) indicating the product’s status.
Crucially, the phrasing is scoped — it is not an assertion that no other Microsoft product contains the code. Vendors commonly start VEX/CSAF rollouts with a single product to establish high‑confidence, machine‑readable attestations before expanding to other product families. The consequence for defenders is clear: treat Microsoft’s VEX/CSAF attestation as authoritative for the named product (Azure Linux), and treat the absence of a published attestation for other Microsoft products as absence of attestation rather than definitive proof of non‑inclusion.

---

The technical reality: where the vulnerability lives and why that matters​

What the bug is, in practical terms​

• The bug concerns the MPTCP path manager counter add_addr_accepted.
• During a remove-subflow sequence (RM_ADDR followed by subflow closure), the counter could be decremented erroneously because the code assumed a matching MP_JOIN had created the subflow context earlier.
• The patch added checks so the counter is decremented only for MP_JOIN-created attached subflows meeting specific conditions, eliminating the incorrect decrement path discovered by tests and KASAN instrumentation.

Where you’ll see the code: kernels, configs, and builds​

MPTCP is not a userland library you can update independently; it is compiled into or as part of the kernel. As a result, artifact‑level differences (distribution kernel vs. vendor kernel vs. WSL kernel vs. custom builds) determine whether an environment is vulnerable:

• If CONFIG_MPTCP is set (built-in or module), the MPTCP subsystem and associated path manager code are present. If that kernel version falls within the affected upstream commit range and missing the upstream fix, the artifact is potentially vulnerable.
• If CONFIG_MPTCP is not set in the kernel config used to build the artifact, the MPTCP code is absent and the artifact is not affected by this specific CVE.

Because Microsoft maintains multiple distinct Linux artifacts (Azure Linux distribution images, the WSL2 kernel builds, linux-azure kernels, AKS node images and Marketplace images), each artifact must be treated as a separate inventory item for MPTCP inclusion and for CVE mapping. Microsoft’s VEX rollout deliberately started with Azure Linux; that product was inventoried first.

---

Is Azure Linux the only Microsoft product that includes the library and could be affected?​

Short answer: No — not necessarily.
Longer, practical answer: Microsoft has explicitly attested that Azure Linux includes the implicated upstream component for this CVE — that is an authoritative statement for Azure Linux and should trigger immediate patch actions for affected Azure Linux hosts. However, Microsoft’s attestation for Azure Linux is a scoped inventory result, not a global guarantee that other Microsoft products are free of the same code. Other Microsoft‑distributed kernels and images can include the MPTCP subsystem depending on kernel version and build-time CONFIG flags, and thus could be affected until they are separately inventoried and attested. Examples of plausible Microsoft artifacts to verify include:

• The WSL2 kernel builds Microsoft publishes and maintains for Windows Subsystem for Linux.
• linux-azure / kernel images used by some Azure VM SKUs (the host‑side / guest kernel stacks for Azure VMs).
• AKS node images and vendor-provided node VM images that include Microsoft-managed kernels.
• Azure Marketplace images where Microsoft or a partner supplies kernel binaries or packages.
• CBL‑Mariner derived artifacts or any Microsoft internal test or appliance images that bundle kernels.

The operational implication is a straightforward inventory task: do not assume that lack of a published VEX attestation == safe. Treat un‑attested Microsoft artifacts as “unverified” and scan or inspect them.

---

Evidence and cross‑checks: what public artifacts show today​

Two independent, verifiable signals are useful for operators:

• Upstream and vendor advisories show the CVE and patch information. NVD and multiple distribution advisories (Ubuntu, Red Hat, Amazon Linux) list CVE‑2024‑45009 and the kernel fix details, confirming the upstream description and patch approach. These advisories are the canonical record of the vulnerability and fix.
• Microsoft’s VEX/CSAF rollout and blog (October 22, 2025) explicitly notes that Microsoft began publishing machine‑readable VEX attestations starting with Azure Linux and will expand coverage. That blog explains the phased approach and why a product‑scoped attestation is useful, and Microsoft’s CVE pages reference the same language: Azure Linux is the product Microsoft has confirmed includes the component and therefore is potentially affected. This is the primary source for the wording you quoted.
• WSL2 kernel configs published by the community and Microsoft-derived builds: public WSL2 kernel configuration files show that in many Microsoft-supplied WSL kernel builds CONFIG_MPTCP is not set (that is, the default WSL kernel configuration typically does not enable MPTCP). That’s strong evidence that, for most default WSL2 kernels, the MPTCP subsystem is not present and therefore that specific artifact is not affected — but it is not a substitute for per‑build verification. You must check the specific kernel image or the distribution image you run.

Taken together: Azure Linux is a confirmed carrier per Microsoft; many WSL kernels appear to be built without MPTCP by default; other Microsoft artifacts remain unverified until Microsoft completes attestation for them or until you verify those artifacts yourself.

---

How to confirm whether a given Microsoft artifact (or any Linux image) is affected — step‑by‑step checklist​

The single most reliable approach is to inspect the specific artifact (kernel binary, image, or package). Here is an operational checklist you can use immediately.

• Gather artifact metadata
• Record the kernel version (uname -r), distribution release, and package names. On the target VM/image run:
• uname -r
• cat /etc/os-release
• rpm -qa | grep kernel or dpkg -l | grep linux-image
• Check kernel configuration for MPTCP
• Many distributions include the kernel config at /boot/config-$(uname -r) or /proc/config.gz. Run:
• grep -E 'CONFIG_MPTCP' /boot/config-$(uname -r) || zgrep CONFIG_MPTCP /proc/config.gz
• If you see CONFIG_MPTCP=y or =m, the MPTCP subsystem is present in the kernel build. If CONFIG_MPTCP is not set, the subsystem is absent.
• Check runtime knobs and MPTCP sysctls
• If the kernel includes MPTCP, sysctl entries usually exist. Try:
• sysctl -a | grep mptcp
• or: sysctl net.mptcp.enabled
• Similar ip mptcp subcommands are available on kernels built with the userspace path manager (iproute2 support).
• Search the binary and modules
• For kernels built as modules, look for mptcp‑related modules; for monolithic kernels, search kallsyms:
• grep -i mptcp /proc/kallsyms || dmesg | egrep -i 'mptcp|mp_join|add_addr_accepted'
• Inspect kernel package changelogs to match upstream commit IDs referenced in vendor advisories.
• Map kernel version to upstream fixes
• Find your kernel’s upstream version and consult the vendor advisory or upstream commit list to determine if your kernel contains the fix (many vendors list fixed package versions). If your kernel is within an affected upstream range and lacks the fix, treat it as vulnerable.
• For artifacts you cannot inspect (Marketplace images, appliance images, WSL binaries)
• Request the vendor attestation (VEX/CSAF) or a kernel config dump, or rely on vendor advisories. Microsoft’s VEX output is authoritative for Azure Linux; for other Microsoft artifacts request the same level of attestation or perform a local inspection when possible.

---

Remediation and mitigation guidance​

• For Azure Linux customers: follow Microsoft’s published update guidance and apply the kernel updates Microsoft publishes for Azure Linux. The VEX/CSAF attestation means Microsoft has inventoried the product and will publish a remediation path or patched images. Prioritize patching and rebooting guest VMs into the fixed kernel when Microsoft marks the product as “Fixed.”
• For other Linux distributions: apply vendor kernel updates as they become available. Ubuntu, Red Hat, Amazon Linux and others have published advisories listing fixed kernel package versions — upgrade to the vendor-released fixed kernels and reboot.
• For WSL2 users:
• Default Microsoft WSL kernels historically show CONFIG_MPTCP not set; many published WSL kernels have MPTCP disabled. But distributions or custom WSL kernel builds might enable MPTCP. If you use the default Microsoft WSL kernel, check the kernel config in your WSL instance and update the kernel image if Microsoft publishes a patched WSL kernel build or you maintain a custom kernel.
• For cloud fleets and Marketplace images:
• Inventory and policy automation: gather kernel versions and /boot/configs across your fleet and match against vendor advisories and VEX/CSAF statements. If you run Marketplace images or partner appliances, request kernel provenance and attestations from the image publisher. Automate this process so attestation changes or new VEX entries trigger alerts.
• Mitigations when immediate patching is impossible:
• Reduce local access and privilege elevation pathways to reduce the likelihood of a local exploit being weaponized.
• Harden host-level security: disable unused features, restrict netlink and other privileged interfaces where possible, and apply kernel hardening sysctls and seccomp/BPF restrictions to untrusted containers and workloads.
• Monitor for kernel oopses and KASAN traces that reference MPTCP or the offending function names; capture and triage any kernel crashes.

---

Risk analysis: how worried should you be?​

• CVE‑2024‑45009’s specifications and vendor advisories place the vulnerability in the local attack vector category — an attacker needs local access (or the ability to create or manipulate subflows locally) to trigger the problematic code path. The typical impact classification is denial‑of‑service due to kernel instability; there is no widely published public exploit circulation for this specific CVE that elevates it to a critical remote exploit. However, kernel defects that manifest as use‑after‑free or incorrect resource lifetime handling can sometimes be escalated into privilege escalation or remote abuse in complex environments, so caution is warranted.
• The operational severity depends on your exposure:
• If your workloads run on Azure Linux images (attested), treat it as high priority to update because Microsoft has explicitly confirmed inclusion and will provide patched images or package updates.
• If you run WSL2 on developer machines, the risk is lower in many cases because many official WSL kernels are built without MPTCP; still, verify your specific kernel and update if necessary.
• If you run custom kernels, Marketplace images, or third‑party appliances, inventory and verify those artifacts immediately. Unverified Microsoft artifacts are blind spots until attested.

---

Practical recommendations for administrators​

• Immediately: inventory all Linux kernels across your estate (cloud VMs, on‑prem VMs, developer desktops running WSL, container hosts).
• Verify MPTCP presence in each kernel via /boot/config and sysctl checks; escalate any kernel that includes MPTCP and matches affected upstream versions to patching priority.
• For Azure Linux workloads, follow Microsoft’s update guidance and watch the VEX attestation for status changes (Known Affected, Fixed, Not Affected).
• For WSL and developer environments, ensure developer guidance is published and enforced: instruct developers to check their WSL kernel config or rely on managed WSL updates from Microsoft (or your internal images).
• Automate: ingest vendor VEX/CSAF feeds when available and integrate them into your vulnerability management pipeline so you can map vendor attestations to your installed artifacts quickly.

---

Strengths and limits of Microsoft’s VEX/CSAF approach — a critical look​

Microsoft’s approach to publish machine‑readable VEX/CSAF attestations starting with Azure Linux is an operationally useful step and a meaningful improvement in vendor transparency. It enables automated decisions based on vendor‑stated product scope and fixed/affected status, which reduces noise and helps with accurate patch targeting for Azure Linux customers. The blog and VEX rollout are positive developments for enterprise security automation.
However, the phased, product‑by‑product rollout creates important operational limits:

• A VEX attestation naming a single product is an affirmative yes for that product but not an affirmative no for all other artifacts. Operators who interpret “Azure Linux is attested” as “no other Microsoft product is affected” introduce potential blind spots.
• Microsoft and other major vendors ship multiple kernel artifacts — WSL kernels, cloud host kernels, marketplace images — that are built from different trees and configs. Without per‑artifact attestations, security owners must perform their own inventories or request attestations for each artifact they rely on.

In short: VEX/CSAF is a notable transparency win, but its current scoped rollout means defenders still need artifact-level verification to close the loop.

---

Conclusion: practical takeaways​

• Azure Linux is the Microsoft product that has been explicitly attested as including the upstream component related to CVE‑2024‑45009; Azure Linux customers must follow Microsoft’s remediation guidance and prioritize updates.
• Azure Linux is not necessarily the only Microsoft product that could include the vulnerable code. Other Microsoft artifacts (WSL2 kernel images, linux‑azure kernels, AKS node images, Marketplace images) should be verified on an artifact-by-artifact basis because kernel inclusion is a build‑time property. Treat the absence of a VEX/CSAF attestation for another Microsoft artifact as unverified, not as proof of safety.
• Operational action items for defenders:
• Inventory kernel versions and configs across your estate.
• Check CONFIG_MPTCP in kernel configs and sysctl entries for MPTCP.
• Patch Azure Linux instances per Microsoft guidance immediately.
• Apply vendor kernel updates (Ubuntu, Red Hat, Amazon Linux, etc.) where relevant.
• For WSL and other developer platforms, validate kernel configs and update managed kernels where Microsoft provides fixes.
• Finally, treat VEX/CSAF as an authoritative and welcome tool for automation and clarity, but not as a replacement for artifact-level inventory and verification until vendor attestations cover the full breadth of artifacts you run.

If you manage Linux fleets — cloud, edge, or developer machines — prioritize inventory and automation now. The difference between a confirmed attestation (Azure Linux) and an unverified artifact can be decisive when a kernel CVE affects availability or escalates into a more severe risk.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center