CVE-2026-43029: Linux Kernel DoS Vulnerability

CVE-2026-43029 Overview

CVE-2026-43029 is a denial-of-service vulnerability in the Linux kernel's Multipath TCP (MPTCP) implementation. The flaw resides in the mptcp_recvmsg() function within net/mptcp/protocol.c. When an application calls recvmsg() with both MSG_PEEK and MSG_WAITALL flags set, the socket buffer (skb) is not removed from the sk_receive_queue. This causes sk_wait_data() to repeatedly find available data and never enter an actual wait state, producing an infinite loop. The condition was reported by syzbot and manifests as a soft lockup that stalls a CPU. A remote peer that can send data to an MPTCP socket can trigger the lockup against any process using these flags.

Critical Impact
A network-reachable attacker can trigger a CPU soft lockup in the Linux kernel through MPTCP receive processing, resulting in denial of service against affected hosts.

Affected Products

Linux kernel with MPTCP support enabled
Linux kernel version 6.19.0-rc8 (confirmed in the syzbot trace)
Stable kernel branches receiving the patches 58b58b9, 5dd8025, and de3c248

Discovery Timeline

2026-05-01 - CVE-2026-43029 published to NVD
2026-05-03 - Last updated in NVD database

Technical Details for CVE-2026-43029

Vulnerability Analysis

The defect is an infinite-loop denial of service in MPTCP receive handling. The kernel call trace captured by syzbot shows CPU#2 stuck for 156 seconds inside sk_wait_data+0x15/0x190, called from mptcp_recvmsg+0x547/0x8c0, reachable through inet_recvmsg, sock_recvmsg, and the recvfrom syscall path. The receive loop repeatedly inspects the queue, finds the same peeked skb, and never blocks or makes forward progress. While the CPU is wedged in this loop, the kernel watchdog raises a soft lockup warning and the affected task cannot be preempted out of kernel mode for normal scheduling.

The condition affects availability only. There is no memory corruption, no privilege boundary crossing, and no information disclosure component. Exploitation requires no authentication and no user interaction beyond an application performing a peek-and-wait read on an MPTCP socket exposed to attacker-controlled input.

Root Cause

When recvmsg() is invoked with MSG_PEEK | MSG_WAITALL, the kernel must satisfy the MSG_WAITALL semantics by waiting for the full requested length while preserving data in the queue per MSG_PEEK. The original implementation called sk_wait_data() without tracking which skb had already been peeked. Because the peeked skb remains on sk_receive_queue, the wait helper observed available data and returned immediately, restarting the loop without progress.

Attack Vector

The attack vector is network. A remote peer sending data on an established MPTCP connection to a server that issues recvmsg() with MSG_PEEK | MSG_WAITALL and a length larger than the supplied data can hold a kernel thread in a tight loop. No exploit code is publicly available, and the issue is not listed in CISA KEV. The fix introduces a last parameter that tracks the most recently peeked skb, allowing sk_wait_data() to recognize when no new data has arrived and to actually block instead of spinning. The corrective patches are 58b58b9, 5dd8025, and de3c248 in the upstream stable tree.

Detection Methods for CVE-2026-43029

Indicators of Compromise

Kernel log entries containing watchdog: BUG: soft lockup - CPU#<n> stuck for <N>s! with the stuck task's call trace including mptcp_recvmsg and sk_wait_data.
Sustained 100% CPU utilization on a single core attributed to a process performing MPTCP receives.
Application-level hangs or timeouts on services that accept MPTCP connections from untrusted peers.

Detection Strategies

Parse dmesg and /var/log/kern.log for soft lockup warnings whose stack traces reference mptcp_recvmsg+ or sk_wait_data+.
Correlate process-level CPU spikes with active MPTCP sockets enumerated via ss -M or /proc/net/mptcp.
Track running kernel versions across the fleet and flag hosts on unpatched releases that have MPTCP enabled (net.mptcp.enabled=1).

Monitoring Recommendations

Forward kernel ring buffer events to a central log pipeline and alert on soft lockup strings tied to MPTCP symbols.
Monitor per-CPU softirq time and system CPU on hosts running MPTCP-capable workloads.
Audit applications that use MSG_PEEK | MSG_WAITALL against MPTCP sockets and inventory their network exposure.

How to Mitigate CVE-2026-43029

Immediate Actions Required

Apply the upstream stable kernel patches 58b58b9, 5dd8025, and de3c248 and reboot affected hosts.
Track distribution security advisories and update to the first vendor kernel build that incorporates the last parameter fix in mptcp_recvmsg().
Inventory hosts where MPTCP is enabled and prioritize patching those exposed to untrusted networks.

Patch Information

The fix adds a last parameter so that sk_wait_data() can determine whether new data has arrived since the previous peek, eliminating the spin loop when MSG_PEEK | MSG_WAITALL is used. The change is committed in upstream stable kernels through patches 58b58b9, 5dd8025, and de3c248. Backports will appear in long-term support kernel branches and in distribution kernels as vendors integrate them.

Workarounds

Disable MPTCP at runtime where it is not required by setting net.mptcp.enabled=0 via sysctl.
Restrict MPTCP listeners to trusted networks using firewall rules until kernels are patched.
Where source code is controlled, avoid combining MSG_PEEK with MSG_WAITALL on MPTCP sockets exposed to untrusted clients.

bash

# Configuration example: disable MPTCP until patched kernels are deployed
sudo sysctl -w net.mptcp.enabled=0
echo 'net.mptcp.enabled=0' | sudo tee /etc/sysctl.d/99-disable-mptcp.conf

# Verify current setting and check for soft lockup traces involving MPTCP
sysctl net.mptcp.enabled
dmesg | grep -E 'soft lockup|mptcp_recvmsg|sk_wait_data'