Linux Kernel EUVD-2026-26628

Target system must be running Linux kernel 6.18 through 6.19-rc8 compiled with CONFIG_MPTCP=y. Victim application must create MPTCP sockets (IPPROTO_MPTCP) rather than standard TCP, and must call recv()/recvmsg() with both MSG_PEEK and MSG_WAITALL flags simultaneously - an uncommon pattern outside specialized network proxies or protocol analyzers. MPTCP must be enabled via sysctl (net.mptcp.enabled=1, which is default if compiled). Attack vector is network-based (AV:N) requiring attacker to initiate MPTCP connection to vulnerable service. No authentication (PR:N) or user interaction (UI:N) required once connection is established. Standard TCP-only applications are NOT vulnerable even on affected kernels. Key limiting factor: MPTCP deployment is rare - primarily found in mobile networks, specific CDN configurations, and research/testing environments, not typical enterprise servers.

Real-world risk is LOW despite the 7.5 CVSS score. The CVSS vector (AV:N/AC:L/PR:N/UI:N) indicates network-accessible unauthenticated attack with low complexity, but several factors reduce practical risk: (1) EPSS of 0.02% (4th percentile) suggests security researchers and attackers are not actively targeting this, (2) Not present in CISA KEV, indicating no confirmed exploitation, (3) Requires victim application to specifically use MPTCP sockets with the unusual combination of MSG_PEEK and MSG_WAITALL flags - most applications use standard TCP or don't combine these flags, (4) Impact limited to availability (CPU soft lockup) with no confidentiality or integrity impact, (5) MPTCP itself is not widely deployed compared to standard TCP. This is primarily a concern for specialized environments running MPTCP-aware applications (load balancers, proxy servers, mobile networks using MPTCP for cellular/WiFi bonding). Attack complexity is genuinely low IF the target uses MPTCP, but deployment prevalence is the key limiting factor. Priority should be MEDIUM for MPTCP users, LOW for standard deployments.

Remote attacker sends a TCP SYN packet with MPTCP option to a server running vulnerable kernel with MPTCP-aware application (e.g., nginx with MPTCP module, custom proxy). Upon connection establishment, attacker sends a small MPTCP data packet. The victim application calls recvmsg() with MSG_PEEK | MSG_WAITALL flags to examine data without consuming it. This triggers the infinite loop in mptcp_recvmsg() where sk_wait_data() continuously finds the peeked skb still in queue, never actually waiting, spinning one CPU core to 100% usage indefinitely. The soft lockup watchdog eventually fires after 120+ seconds but the condition persists. No exploit code publicly identified at time of analysis, but exploitation is trivial given the simple trigger condition.