CVE-2026-97524: mptcp: avoid unneeded actions on subflow reset
In the Linux kernel, the following vulnerability has been resolved:
mptcp: avoid unneeded actions on subflow reset
Once in a blue moon, the mptcp receive path can recursively call mptcpdataready() via state change under unlucky error conditions, and then try to hold the data lock again.
Break the recursion loop explicitly checking for the exceptional condition.
Add a new flag instead of using an existing one like 'closing', to exit early in subflowstatechange(), and explicitly flush the RX queue at reset time.
This avoids unneeded processing to check for available data -- calling getmappingstatus() and more on a dying subflow -- but also in error reporting and worker scheduling.
Note that we must consume the currently peeked skb before invoking mptcpdsscorruption to avoid consuming it again after the eventual reset has freed it.
Affected Software
Event History
Frequently Asked Questions
Which systems are potentially exposed to this issue?
Systems using the Linux kernel's Multipath TCP (MPTCP) receive path may be affected. The issue is tied to exceptional subflow reset and error conditions rather than ordinary receive processing.
What conditions are needed to trigger the problem?
The problem requires an unlucky error condition in which the MPTCP receive path recursively invokes mptcp_data_ready() through a subflow state change. The description does not establish whether this can be triggered by an unauthenticated remote peer or requires a particular network setup.
What is the practical effect of the fix?
The fix prevents recursive re-acquisition of the MPTCP data lock during a subflow reset. It also stops processing on the dying subflow, flushes its receive queue at reset time, and avoids re-consuming a previously peeked packet after reset.