In the Linux kernel, the following vulnerability has been resolved: mptcp: avoid unneeded actions…

Why it is Amber

• CVSS 7.5 high
• Remotely exploitable without logging in
• On your watchlist: linux kernel

References

• https://git.kernel.org/stable/c/1962841387087970d75ba8b8d4c2aa2d45705e50
• https://git.kernel.org/stable/c/2b0f561f21b27c40c91ea4975268a06092bd7e9c
• https://git.kernel.org/stable/c/4b7abdcb5ba832fafab679f0d998af39cbc99307
• https://git.kernel.org/stable/c/6d669c740933124eae3df8cfc15995af9bcc6aba
• https://git.kernel.org/stable/c/83a7dcdd2b1060484528da70a643125174d47e5a
• https://git.kernel.org/stable/c/a370e56024df0b07e3120c45a9773ae123819fd6
• https://git.kernel.org/stable/c/b2dbcc1ed48b5ac070a41db4a52aade6823c4df0
• https://git.kernel.org/stable/c/ce7e4ede01ed3e47a48c0f1ce1d87bf4864bee9f

Original description

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 mptcp_data_ready() 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 subflow_state_change(), and explicitly flush the RX queue at reset time. This avoids unneeded processing to check for available data -- calling get_mapping_status() 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 mptcp_dss_corruption to avoid consuming it again after the eventual reset has freed it.