CVE-2026-43029

What it actually does

This is a Linux kernel denial-of-service flaw in the Multipath TCP (MPTCP) receive path. When an application receives MPTCP data using MSG_PEEK together with MSG_WAITALL, the socket buffer is not removed from the receive queue, so mptcp_recvmsg() can repeatedly observe the same data and call sk_wait_data() without making progress. The result is a kernel soft lockup on the affected CPU, potentially causing high CPU consumption, stalled networking workloads, watchdog events, and service unavailability. The issue does not provide confidentiality or integrity impact and is not known to enable code execution or privilege escalation.

Why it matters to the business

Systems running affected Linux kernels with MPTCP-enabled workloads may become slow, unresponsive, or unavailable if the vulnerable receive path is triggered. Internet- or network-facing services that use MPTCP are the highest concern because an unauthenticated network actor may be able to induce availability loss depending on application behavior. The EPSS score is currently low and stable, the vulnerability is not listed in CISA KEV, and no public exploit maturity is reported, but the CVSS availability impact is high, so critical MPTCP-dependent services should still prioritize kernel updates through normal emergency or accelerated maintenance windows.

How an attack unfolds

An attacker targets a service running on a vulnerable Linux kernel where MPTCP is enabled and the application receive logic can call recvmsg, recvfrom, or an equivalent socket API with MSG_PEEK and MSG_WAITALL. The attacker establishes or interacts with an MPTCP connection and sends data in a way that leaves data visible on the receive queue while the application peeks instead of consuming it. Because the vulnerable kernel does not correctly track the last peeked socket buffer, sk_wait_data() continues to believe data is immediately available and mptcp_recvmsg() can loop without meaningful waiting or progress. This can pin a CPU in kernel context, trigger soft-lockup watchdog messages, degrade service performance, and in severe cases cause broader host instability or application outage. Exploitation is availability-focused and depends on MPTCP being enabled and reachable plus an application code path that uses the affected flag combination.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix for the MPTCP mptcp_recvmsg() soft-lockup condition. Because no exact fixed package versions were provided, use the latest security kernel from the operating system or appliance vendor and confirm the vendor advisory explicitly references this CVE or the MPTCP recvmsg MSG_PEEK/MSG_WAITALL fix. Reboot into the patched kernel after installation; installing kernel packages alone is insufficient if the system continues running the old kernel. Where immediate patching is not possible, reduce exposure by disabling MPTCP if it is not required, restricting access to MPTCP-enabled services, placing affected services behind rate limiting or access controls, and reviewing applications that use MSG_PEEK with MSG_WAITALL on MPTCP sockets.

How to confirm the fix worked

Confirm the running kernel, not just the installed kernel package, has been updated to a vendor build containing the fix. Verify MPTCP exposure by checking whether MPTCP is enabled and whether services are listening on paths that can negotiate MPTCP. On Linux systems, review sysctl and runtime state such as net.mptcp.enabled where applicable, and validate package status with the platform’s package manager and vendor advisory metadata. After remediation, reboot and confirm the active kernel version matches the patched package. For functional validation, monitor that MPTCP workloads no longer generate kernel soft-lockup messages involving mptcp_recvmsg(), sk_wait_data(), inet_recvmsg(), sock_recvmsg(), or recvfrom under legitimate traffic and regression testing.

Typical attack path

1. Identify a Linux-hosted service that supports or negotiates Multipath TCP.
2. Establish a network connection to the service over MPTCP.
3. Send data patterns that cause the server-side application to enter a receive path using MSG_PEEK and MSG_WAITALL.
4. Keep the connection active or repeat the interaction so the same socket buffer remains visible in the receive queue.
5. Trigger repeated mptcp_recvmsg() and sk_wait_data() execution without forward progress.
6. Cause CPU soft lockup, service degradation, or denial of service.

How to detect it

To determine whether this was already exploited or triggered, review kernel logs, system journals, crash dumps, watchdog alerts, and performance telemetry for soft-lockup events involving MPTCP receive handling. Primary sources include /var/log/kern.log, /var/log/messages, journalctl -k output, dmesg history, kernel crash dumps, EDR telemetry, uptime/performance monitoring, and network flow records for MPTCP traffic around the time of CPU saturation or service stalls. Look for call traces containing mptcp_recvmsg(), sk_wait_data(), inet_recvmsg(), sock_recvmsg(), __sys_recvfrom(), or recvfrom in combination with watchdog soft lockup messages. Correlate timestamps with unexplained CPU pegging, application unresponsiveness, TCP/MPTCP connection spikes, repeated reconnects, or traffic from a small number of remote sources. Because this flaw does not create a durable file artifact or known malware indicator, detection should focus on kernel telemetry and network/session correlation rather than host persistence indicators.

• watchdog: BUG: soft lockup
• soft lockup - CPU#
• mptcp_recvmsg
• sk_wait_data
• inet_recvmsg
• sock_recvmsg
• __sys_recvfrom
• __x64_sys_recvfrom
• entry_SYSCALL_64_after_hwframe
• recvfrom
• MSG_PEEK
• MSG_WAITALL
• net/mptcp/protocol.c
• net/socket.c
• net/ipv4/af_inet.c
• CPU#2 stuck for
• Comm: server Not tainted

What your security team should do

• Inventory Linux systems and appliances with MPTCP enabled, prioritizing internet-facing and high-availability services.
• Apply vendor kernel updates that include the MPTCP recvmsg fix, then reboot to activate the patched kernel.
• If MPTCP is not business-critical, disable it as a short-term or permanent hardening measure.
• Restrict network access to MPTCP-capable services until patched, especially from untrusted networks.
• Ask application owners whether services use MSG_PEEK and MSG_WAITALL on sockets, and prioritize those workloads for testing and remediation.
• Add monitoring for kernel soft lockups and call traces containing mptcp_recvmsg or sk_wait_data.
• Treat repeated soft-lockup events on MPTCP servers as potential denial-of-service activity and investigate associated network connections.
• Because this is not currently in KEV and EPSS is low, align remediation with risk-based kernel patch cycles unless the affected system is exposed or operationally critical.