CVE-2025-23145: Linux MPTCP Patch Prevents Kernel Panics

The Linux kernel patch for CVE-2025-23145 fixes a subtle but real NULL-pointer dereference in the Multipath TCP (MPTCP) code — a bug that can cause kernel panics and availability outages on systems whose kernels include MPTCP support. Microsoft’s public advisory language that “Azure Linux includes this open‑source library and is therefore potentially affected” is correct as a product-level attestation, but it is not an exclusivity guarantee: Azure Linux is the only Microsoft product explicitly attested so far, yet other Microsoft-distributed kernel artifacts may still include the same upstream MPTCP code depending on how those kernels were built.

---

Background / Overview​

MPTCP is an upstream Linux kernel feature that allows a single TCP connection to use multiple network paths (subflows) simultaneously — useful for bandwidth aggregation, mobility use cases, and resilience. The Linux MPTCP stack lives in net/mptcp in upstream sources and is toggled at compile time with kernel config options such as CONFIG_MPTCP. Many mainstream distributions enable MPTCP in their kernel builds, and user-land must opt in to use it (IPPROTO_MPTCP or sysctl configuration).
CVE-2025-23145 was assigned for a NULL-pointer dereference in the function mptcp_can_accept_new_subflow (net/mptcp/subflow.c). Under a race — e.g., when the same connection request receives rapid duplicate SYN-ACKs processed concurrently on multiple CPUs — a pointer named subflow_req->msk can be transferred away by one CPU while another CPU still assumes it’s present. That can lead to dereferencing a NULL pointer and a kernel panic (availability impact). The National Vulnerability Database (NVD) lists the issue and assigns a Medium base score with an Availability impact and a local attack vector.
Why this matters operationally: kernel panics or repeated crashes are high-impact events for servers, appliances, or multi-tenant hosts. The vulnerability is not a remote code execution or confidentiality leak — its primary risk is denial of service (system crash / availability loss) — but it can be triggered by malformed or racey network conditions and by certain test/benchmark tools that exercise MPTCP behavior.

---

The technical fault: what went wrong inside MPTCP​

• The vulnerable path lives in net/mptcp/subflow.c, inside mptcp_can_accept_new_subflow.
• The root cause is a race around ownership/transfer of a socket/request structure (subflow_req) and a member pointer (msk).
• If one CPU transfers ownership of subflow_req->msk to a new subflow while another CPU concurrently evaluates the same request, the latter can see the pointer as NULL and dereference it.
• The upstream patch moves the ownership transfer and related checks so that the pointer isn’t referenced after ownership has been moved, removing the race window and thus preventing the NULL dereference.

This is a classic concurrency bug in kernel networking code: tiny reorderings, duplicated packets, or aggressive retransmission plus multi-CPU concurrency create a window where ownership semantics must be explicit and protected. The upstream remedy is small and surgical, but until a patched kernel is deployed the availability risk remains for systems that have MPTCP enabled.

---

What Microsoft publicly said — and what that actually means​

Microsoft’s Security Response Center (MSRC) advisories for several kernel CVEs have followed a similar, concise FAQ line: “Is Azure Linux the only Microsoft product that includes this open-source library and is therefore potentially affected?” The published answer frames Azure Linux as the product Microsoft has checked and attested to include the upstream component, while promising to publish CSAF/VEX attestations and to update mappings if other Microsoft products are later found to include the same code. That is both accurate and intentionally scoped: it is a product-level inventory attestation, not a blanket sweep of every Microsoft image, kernel binary, or Marketplace artifact.
Important operational translation:

• “Azure Linux is attested” = Microsoft has inspected that product family and confirmed the component exists there. Treat Azure Linux images as confirmed in-scope and remediate accordingly.
• “Only Azure Linux is listed” ≠ “No other Microsoft product contains the component.” The absence of additional attestations is not proof of absence; it usually reflects the phased rollout of machine-readable VEX/CSAF attestations and the practical challenge of inventorying every artifact and kernel build configuration across a massive vendor surface.

WindowsForum community analyses and multiple vendor threads have reached the same operational conclusion: Azure Linux is the only Microsoft product currently attested for a number of kernel CVEs, but many other Microsoft kernel artifacts (WSL2 kernel, linux-azure kernels used in some VM images, Marketplace images, AKS node images, and curated partner images) are separately built and may include the same upstream files depending on CONFIG_* selections and backports. Treat un-attested Microsoft artifacts as “unknown” until proven otherwise.

---

Is Azure Linux the only Microsoft product that could be affected? The short answer​

No — not necessarily.

• Azure Linux is the only Microsoft product Microsoft has publicly attested as including the implicated upstream component for this CVE so far (and that attestation is authoritative for that product family).
• However, Microsoft ships multiple Linux kernel artifacts across its product lines. Whether those artifacts include the vulnerable MPTCP code depends on the kernel version, upstream commit range, and crucially the build-time configuration flags (for example, CONFIG_MPTCP). Those are per-artifact properties and require either Microsoft attestations or direct inspection to confirm.

In practice, defenders should treat Azure Linux as “confirmed affected” and other Microsoft-distributed kernels/images as “unverified — potentially affected” until Microsoft updates the VEX/CSAF mapping or explicit inspection shows otherwise.

---

How to determine if a given Microsoft artifact (or any Linux host) is affected​

The pragmatic checklist for admins and defenders:

• Identify the kernel artifact
• For VMs: check the image name and kernel package (uname -a; rpm/dpkg or /boot).
• For WSL: check the WSL2 kernel build/version shipped on the host (uname -r inside WSL or examine Microsoft’s WSL kernel binaries/config if you maintain custom kernels).
• Check whether MPTCP support is compiled in
• Inspect the kernel config (often available at /proc/config.gz or shipped as /boot/config-<version>).
• Look for CONFIG_MPTCP (set to y or m) or the string “# CONFIG_MPTCP is not set”.
• If CONFIG_MPTCP is set to y or m, the MPTCP code is present; if it is explicitly not set, the kernel does not include the MPTCP subsystem. Many WSL kernel configs seen in the wild have MPTCP disabled (# CONFIG_MPTCP is not set), but distribution and custom builds vary.
• If the kernel includes MPTCP, check the kernel version / upstream commit range
• Compare your kernel version against the upstream commit that fixed CVE-2025-23145, or consult your distribution/vendor advisory (Ubuntu, RedHat, Oracle, Debian trackers list affected versions and patched releases). Vendors frequently backport fixes, so vendor-specific package versions matter more than a raw upstream version string.
• Runtime detection/controls
• Check the runtime sysctl: net.mptcp.enabled (0 = disabled, 1 = enabled or bitfield depending on kernel); you can temporarily disable MPTCP at runtime with sysctl net.mptcp.enabled=0 where supported to mitigate availability risk until a patched kernel is deployed. Note that disabling MPTCP may impact applications that intentionally use Multipath TCP.
• Consult vendor attestations and advisories
• Use Microsoft’s MSRC update guide and VEX/CSAF attestations for Azure Linux to determine attested exposure; for other Microsoft artifacts, monitor MSRC pages and vendor advisories for updates. Microsoft has started publishing machine-readable VEX/CSAF output (beginning with Azure Linux) to make this mapping clearer over time.

---

Practical mitigation and remediation steps​

• For Azure Linux customers: follow Microsoft’s Azure Linux advisories and apply vendor-provided kernel updates as soon as they are available. Azure Linux is the attested carrier in Microsoft’s advisory for many kernel CVEs, so prioritize patching those images.
• For operators of other Microsoft-distributed artifacts (WSL, Marketplace images, AKS node images, custom appliance kernels):
• Inspect the kernel config (CONFIG_MPTCP) and the kernel package version; if MPTCP is present and the kernel is within the affected commit range, pursue vendor patches or rebuild/redeploy with a fixed kernel.
• As an interim mitigation for hosts where a patch is not immediately available and where MPTCP is enabled, consider setting net.mptcp.enabled=0 to reduce the attack surface and avoid accidental kernel panics. Test application compatibility before enforcing this broadly.
• For WSL users: many publicly distributed WSL kernel configs have MPTCP disabled by default. If you run a custom WSL kernel or a distro image that enables MPTCP, inspect the .config and either apply upstream fixes or disable MPTCP until patched. For many users the default WSL kernel does not enable CONFIG_MPTCP; still, confirm on your environment.
• For enterprise defenders: ingest vendor VEX/CSAF attestations (Microsoft’s attestation set began with Azure Linux in October 2025) into your vulnerability management pipeline. Where vendors have not yet attested every artifact, plan for artifact-level verification (kernel config inspection, package reconciliation) to close the “unknown” gaps.

---

Attack surface, exploitability and urgency​

• Attack vector: Local (AV:L). The CVSS vector and NVD describe the issue as locally reachable — an attacker needs to be able to influence the networking stack locally or deliver crafted packets in a way that the local kernel will process them (e.g., on a server accepting network connections, or via processes capable of sending/receiving packets that exercise MPTCP).
• Complexity: Low. The defect is a race that can be triggered naturally by network retransmissions or duplicates under certain conditions; test tools and edge cases (benchmarks, simulators) have exposed it during diagnosis.
• Privileges: Low – the code can be reached by normal network processing; special privileges beyond network connectivity are not required in many contexts.
• Impact: Availability (kernel panic / host reboot). That makes the flaw high priority for hosts that need high uptime or are multi-tenant.

Given these factors, patching or disabling the MPTCP pathway for vulnerable kernels should be prioritized for critical infrastructure, gateways, and multi-tenant hosts.

---

Why vendor attestation language can be confusing — and how to read it​

Vendors often choose conservative, narrowly scoped language when they say “Product X includes the open-source library and is potentially affected.” That phrasing is:

• Deliberately helpful: it confirms a product-level inventory mapping that customers can trust to automate triage (the core purpose of VEX/CSAF).
• Deliberately limited: it avoids making broad claims about other product families until those other artifacts have been inventoried and analyzed. This minimizes false positives but leaves operational “unknowns” that defenders must treat conservatively.

Microsoft’s rollout of machine-readable VEX/CSAF attestations began with Azure Linux as a logical initial scope (a single product family to inventory and validate). That approach reduces ambiguity for Azure Linux customers, while other Microsoft artifacts will be added to the attestation set as Microsoft completes the mapping work. Until an artifact is attested as Not Affected or Fixed, treat it as “unverified” rather than “safe.”

---

Actionable checklist for operators (quick reference)​

• Inventory: identify all Microsoft-distributed Linux kernels you run (Azure VM images, AKS node images, WSL kernels, Marketplace images).
• Inspect: check kernel config for CONFIG_MPTCP and gather kernel package metadata (uname -r, package manager info).
• Triage: if MPTCP is present and the kernel falls into the affected range, prioritize patching with vendor-supplied or upstream fixed kernels.
• Mitigate: if patching will take time, and MPTCP is enabled, consider temporarily setting net.mptcp.enabled=0 on affected hosts (test first).
• Monitor: subscribe to vendor advisories (MSRC) and ingest VEX/CSAF artifacts into your vulnerability automation pipeline; update your asset mappings when vendors publish new attestations.

---

Risks, open questions and recommended posture​

• Risk of “unknown” Microsoft artifacts: Microsoft attestation of Azure Linux is authoritative for that product family, but it does not prove absence in other Microsoft kernels (WSL2, linux-azure builds, Marketplace images). Operators must either wait for vendor attestations or perform artifact-level validation.
• Operational cost vs. availability risk: disabling MPTCP reduces the immediate crash risk, but it may break legitimate multipath use cases. Evaluate where MPTCP is actively used before disabling cluster-wide. Test changes in stage prior to production.
• Backport complexity: distributors often backport upstream fixes into longterm vendor kernels (RHEL, Ubuntu, Oracle Linux). Don’t rely on upstream version numbers alone — use your distro’s security tracker and package metadata to determine if your kernel has the fix. Ubuntu, Debian and vendor trackers publish the CVE mapping and fixed package versions.
• WSL kernel nuance: many publicly circulated WSL kernel configs show MPTCP disabled by default, but custom kernels or future WSL updates could enable it; verify your WSL kernel config rather than assuming.

---

Conclusion​

CVE-2025-23145 is a real availability risk in the Linux kernel MPTCP subsystem: a race that can produce a NULL-pointer dereference and kernel panic. Microsoft’s public wording that “Azure Linux includes this open‑source library and is therefore potentially affected” is an authoritative, product-scoped attestation for Azure Linux — which should be treated as confirmed in-scope — but it is not a guarantee that other Microsoft-distributed kernel artifacts are free of the same upstream code. For defenders the practical approach is clear: treat Azure Linux as impacted until patched; inspect other Microsoft artifacts (WSL, linux-azure kernels, Marketplace/AKS images) for CONFIG_MPTCP and kernel versions; apply patched kernels or temporary mitigations (net.mptcp.enabled=0) where necessary; and consume vendor VEX/CSAF attestations as they are published to reduce uncertainty.
Apply fixes and mitigations sooner rather than later for any host that runs MPTCP-enabled kernels and serves multi-tenant workloads or critical services — availability outages are the primary risk here, and the remediation is straightforward once you identify which artifacts include the upstream MPTCP code.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center