CVE-2026-43252

What it actually does

This is a local availability flaw in the Linux kernel MPTCP in-kernel path manager. A crafted sequence of MPTCP generic netlink operations involving endpoint removal and flag changes can leave an endpoint ID in an unexpected state and trigger a kernel WARN condition in the MPTCP path-manager code path, including __mark_subflow_endp_available(), mptcp_pm_nl_fullmesh(), and mptcp_pm_nl_set_flags(). On systems configured to panic on kernel warnings, this can crash the host. Even without panic_on_warn, repeated triggering can degrade system stability and flood kernel logs. The CVSS vector indicates local access with low privileges, no user interaction, and impact limited to availability.

Why it matters to the business

An attacker with local access to a Linux system may be able to force a kernel warning and potentially crash the system, causing service interruption for workloads running on that host. The risk is highest on multi-user systems, shared compute platforms, container hosts, CI/build infrastructure, and servers where kernel warnings are configured to cause a panic. The issue is not listed in CISA KEV, has no known ransomware association, and has very low EPSS, so broad internet-scale exploitation is not currently indicated; however, the operational consequence can still be severe where local users or untrusted workloads are present.

How an attack unfolds

An attacker first obtains the ability to execute code locally on an affected Linux host. They then interact with the MPTCP generic netlink interface and submit a crafted sequence of messages that manipulates MPTCP endpoint state, including endpoint removal and flag-setting behavior. The vulnerable kernel path fails to consistently mark an endpoint ID as available after endpoint removal, so a subsequent MPTCP path-manager operation reaches an inconsistent internal state and triggers a WARN at net/mptcp/pm_kernel.c. If the system is configured with kernel.panic_on_warn enabled, the warning escalates into a kernel panic and immediate denial of service. If panic-on-warning is disabled, the attacker may still repeatedly trigger warnings, consume resources, and create noisy kernel logs.

How to fix it

Apply the vendor kernel update that includes the upstream fix for the MPTCP path-manager endpoint-ID handling issue described as "mptcp: pm: in-kernel: always set ID as avail when rm endp." No fixed package versions were provided in the input, so use the latest stable kernel from the Linux distribution or kernel vendor and confirm the relevant patch is included in the changelog or source package. Reboot into the patched kernel after installation; installing the package alone is not sufficient if the vulnerable kernel remains running. As interim mitigation, disable MPTCP where it is not required, for example through the distribution-supported sysctl or kernel configuration for net.mptcp.enabled, and consider disabling panic-on-warning on systems where availability is more important than immediate fail-stop behavior. Limit local shell access and untrusted workload execution on systems that cannot be patched promptly.

How to confirm the fix worked

Confirm the active running kernel is the patched version using uname -r and the distribution package manager, then verify the system has rebooted into that kernel. Review vendor advisories, kernel changelogs, or source patches for the fix string "mptcp: pm: in-kernel: always set ID as avail when rm endp" or related changes in net/mptcp/pm_kernel.c. Check whether MPTCP is enabled using sysctl net.mptcp.enabled or the distribution-equivalent interface. If MPTCP is not needed, validate that it is disabled and remains disabled after reboot. In non-production testing only, use a controlled reproducer or vendor regression test to confirm that MPTCP endpoint removal and flag changes no longer produce a WARN at net/mptcp/pm_kernel.c:1074. Also check kernel.panic_on_warn to understand whether a WARN would still cause a host crash.

Typical attack path

1. Gain local code execution on an affected Linux host, such as through a shell, compromised account, container escape context, or untrusted local workload.
2. Check whether the running kernel has MPTCP support enabled and exposes the MPTCP generic netlink path-manager interface.
3. Send crafted generic netlink messages to the MPTCP path manager to create, remove, and modify endpoint state in a sequence that leaves an endpoint ID inconsistent.
4. Trigger the vulnerable flag-setting path, reaching mptcp_pm_nl_set_flags() and related in-kernel path-manager functions.
5. Cause a kernel WARN in net/mptcp/pm_kernel.c; if panic_on_warn is enabled, crash the host and interrupt running services.

How to detect it

To determine whether this was already exploited, review kernel logs and centralized log sources such as journald, /var/log/kern.log, /var/log/messages, /var/log/syslog, dmesg captures, crash dumps, and kdump/vmcore records. Look for WARN traces referencing net/mptcp/pm_kernel.c, __mark_subflow_endp_available(), mptcp_pm_nl_fullmesh(), mptcp_pm_nl_set_flags_all(), mptcp_pm_nl_set_flags(), or mptcp_pm_nl_set_flags_doit(). Correlate these events with local process execution, auditd syscall records for sendmsg to netlink sockets, and any unusual local users or workloads active at the time. Also look for host reboots or kernel panics immediately following MPTCP-related warnings, especially where kernel.panic_on_warn is enabled. The presence of syzkaller-style process names such as syz.* usually indicates fuzzing or proof-of-concept testing rather than normal application behavior, but attackers may rename tools, so prioritize the kernel trace functions and file paths over process names.

• WARNING: net/mptcp/pm_kernel.c:1074
• __mark_subflow_endp_available
• mptcp_pm_nl_fullmesh
• mptcp_pm_nl_set_flags_all
• mptcp_pm_nl_set_flags
• mptcp_pm_nl_set_flags_doit
• net/mptcp/pm_kernel.c
• net/mptcp/pm_netlink.c:277
• net/mptcp/pm_netlink.c:282
• genl_rcv_msg
• netlink_rcv_skb
• netlink_unicast
• netlink_sendmsg
• netlink: attribute type 5 has an invalid length
• bytes leftover after parsing attributes
• Comm: syz.
• kernel.panic_on_warn
• panic_on_warn

What your security team should do

• Patch affected Linux kernels on multi-user systems, container hosts, shared compute platforms, and internet-facing service hosts first, then reboot to activate the fixed kernel.
• If immediate patching is not possible and MPTCP is not business-critical, disable MPTCP until the fixed kernel can be deployed.
• Inventory systems with MPTCP enabled and kernel.panic_on_warn set to 1, as these have the clearest path from warning to full host outage.
• Restrict local access and untrusted workload execution on unpatched systems, especially where users can run arbitrary code.
• Add monitoring for kernel warnings involving net/mptcp/pm_kernel.c, mptcp_pm_nl_set_flags, and MPTCP generic netlink activity.
• Review kernel logs for historical signs of exploitation or testing, especially unexplained WARN traces followed by reboot events.
• Track vendor advisories for exact fixed kernel package versions because no fixed versions were provided in the input.