Security readout for executives and security teams
Plain-English summary
A flaw in Linux Multipath TCP can trap a CPU in an endless receive loop when software combines specific waiting and data-peeking options. The resulting soft lockup can degrade service availability or contribute to denial of service. The supplied record does not report data theft, modification, or confirmed attacks.
Executive priority
Treat this as a high-priority availability issue on MPTCP-enabled production systems, particularly those serving untrusted networks. Validate vendor applicability promptly and schedule kernel updates through normal emergency-change procedures. Systems demonstrably not using MPTCP likely have lower immediate exposure, but still require version tracking.
Technical view
With MSG_PEEK and MSG_WAITALL, the socket buffer remains on the receive queue. sk_wait_data() repeatedly sees available data and does not genuinely wait, causing an infinite loop in mptcp_recvmsg(). The stable fix tracks the last peeked buffer so waiting decisions can progress correctly.
Likely exposure
Exposure requires an affected Linux kernel and MPTCP receive activity using the relevant flags. The record lists 6.18, 6.18.22, 6.19.12, and 7.0 as affected, but its version representation is incomplete or ambiguous. Confirm applicability through the operating-system vendor.
Exploitation context
The CVSS 3.1 score is 7.5 with a network, low-complexity, unauthenticated availability vector. However, the bundle marks KEV false and provides no evidence of active exploitation. Discovery came from syzbot testing, and the sources do not establish practical remote trigger conditions.
Researcher notes
syzbot reproduced a CPU soft lockup on Linux 6.19.0-rc8 under QEMU. The trace places the loop in sk_wait_data() through mptcp_recvmsg(). Three stable-kernel fixes are referenced. The supplied version arrays mix releases and commit identifiers, so exact affected ranges should not be inferred beyond the record.
Mitigation direction
Upgrade to a vendor-supported Linux kernel incorporating one of the referenced stable fixes.
Confirm vendor-specific package mappings because the supplied affected-version data is ambiguous.
Follow operating-system vendor guidance for temporary risk reduction if an immediate upgrade is impossible.
Prioritize availability-critical systems that actively use MPTCP.
Validation and detection
Inventory running kernel releases and determine which systems use MPTCP.
Confirm the installed kernel includes one of the three referenced stable commits.
Review kernel logs for soft-lockup events involving mptcp_recvmsg or sk_wait_data.
After updating, verify the expected vendor kernel build is running.
Monitor normal MPTCP workloads for recurring receive-path lockups.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-43029 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
0ADP providers
4Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.