CVE-2026-89554
massUninitialized local_id in Linux kernel MPTCP SYN-cookie MP_JOIN handling
The Linux kernel's MPTCP implementation fails to restore the local_id field when rebuilding a request socket from a saved SYN-cookie entry for an MP_JOIN 4th-ACK, in mptcp_token_join_cookie_init_state(). Because the request-sock slab is SLAB_TYPESAFE_BY_RCU and not zeroed on allocation, subflow_ulp_clone() reads a stale byte from a previously freed request socket as the joined subflow's address-ID. An off-path attacker can influence that stale value by sending concurrent MP_JOIN SYNs to a server that is issuing SYN cookies (e.g., under SYN-flood load), corrupting the path manager's ID-based subflow bookkeeping. The impact is primarily availability (CVSS 8.2, A:H) with limited integrity impact and no confidentiality impact for any host terminating MPTCP connections with a vulnerable kernel. No public proof of concept is known and the flaw is not listed in CISA's KEV, so there is no evidence of exploitation in the wild.
What to do: Apply distribution kernel updates once the fix (restoring local_id in mptcp_token_join_cookie_init_state()) lands in your vendor's packages and reboot into the patched kernel. If patching is delayed, consider disabling MPTCP (blacklisting mptcp-related modules or blocking MPTCP option traffic) on internet-facing MPTCP servers, especially those prone to SYN floods. Watch for MPTCP connection resets or inconsistent subflow/address-ID bookkeeping on multihomed servers as indicators of attempted abuse.
| Linux kernel (MPTCP subsystem) | — |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
In the Linux kernel, the following vulnerability has been resolved: mptcp: fix uninitialized local_id in syncookie MP_JOIN reconstruction mptcp_token_join_cookie_init_state() restores remote_nonce, local_nonce, backup, join_id, token and msk from the saved cookie entry when rebuilding the request socket for a MP_JOIN 4th-ACK handled under SYN cookies, but it does not restore local_id, even though the SYN path saved it. subflow_ulp_clone() then reads that uninitialized field and stores it as the joined subflow's address-ID. Because the request-sock slab is SLAB_TYPESAFE_BY_RCU and not zeroed on allocation, the value is the stale byte of a previously freed request socket, which an off-path peer can influence by sending concurrent MP_JOIN SYNs. This corrupts the path manager's id-based subflow bookkeeping for the connection. Restore subflow_req->local_id from the cookie entry, as done for the other fields.
- Vector
- CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H
In the news0 stories
No ingested article mentions this CVE yet.