In the Linux kernel, the following vulnerability has been resolved:
mptcp: close race between scheduler and state change
The mptcp scheduler may race with subflow sockets state change: data
transmission on the selected socket may fail and a later release could
try to use mss_now reset to 0 for a divide operation.
Address the issue by explicitly checking for the critical scenario.
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
CVSS Score: 7.5
AV:N - mptcp_push_release is reached from __mptcp_push_pending after mptcp_sched_get_send. A remote MPTCP peer changes the selected subflow's sk_state via TCP RST/FIN (tcp_v4_rcv/tcp_rcv_established/tcp_reset) without the msk lock, and a DSS DATA_ACK (mptcp_incoming_options→ack_update_msk) sets MPTCP_PUSH_PENDING so mptcp_release_cb calls that push.
AC:L - The attacker creates both halves of the race: they induce __mptcp_push_pending (DSS DATA_ACK, or eliciting mptcp_sendmsg) so mptcp_subflow_get_send snapshots __tcp_can_send without the ssk lock, then RST/FIN/MP_FAIL that subflow before lock_sock; the window is attacker-timed and retryable, not an uninfluencable layout.
PR:N - Completing MP_CAPABLE to an IPPROTO_MPTCP listener needs no account or capability; net.mptcp.enabled defaults to 1 in mptcp pernet init, and tcp_rcv_established/mptcp_incoming_options apply no application credentials before the DATA_ACK and RST/FIN that cause this race.
UI:N - The attacker sends the DATA_ACK and RST/FIN themselves and supplies the request that makes the service call mptcp_sendmsg; no victim mount, click, or extra confirmation is required.
S:U - The divide-error runs in tcp_tso_autosize/tcp_set_skb_tso_segs on the host kernel MPTCP/TCP socket; it does not cross a VM, IOMMU, or sandbox boundary.
C:N - When __tcp_can_send fails in mptcp_sendmsg_frag, info->mss_now stays 0 and tcp_push divides by zero; that CPU exception does not read freed objects or out-of-range kernel memory.
I:N - tcp_write_xmit aborts on the divide in tcp_tso_autosize/tcp_set_skb_tso_segs before modifying TCP control blocks or packet contents; this is not an OOB/UAF write or control-flow hijack.
A:H - bytes/mss_now in tcp_tso_autosize and DIV_ROUND_UP(skb->len, mss_now) in tcp_set_skb_tso_segs raise a kernel divide-error oops/panic from mptcp_push_release, and the attacker can repeat it across MPTCP connections.
| Attack Vector |
Network |
Scope |
Unchanged |
| Attack Complexity |
Low |
Confidentiality Impact |
None |
| Privileges Required |
None |
Integrity Impact |
None |
| User Interaction |
None |
Availability Impact |
High |
AV:N - mptcp_push_release is reached from __mptcp_push_pending after mptcp_sched_get_send. A remote MPTCP peer changes the selected subflow's sk_state via TCP RST/FIN (tcp_v4_rcv/tcp_rcv_established/tcp_reset) without the msk lock, and a DSS DATA_ACK (mptcp_incoming_options→ack_update_msk) sets MPTCP_PUSH_PENDING so mptcp_release_cb calls that push.
AC:L - The attacker creates both halves of the race: they induce __mptcp_push_pending (DSS DATA_ACK, or eliciting mptcp_sendmsg) so mptcp_subflow_get_send snapshots __tcp_can_send without the ssk lock, then RST/FIN/MP_FAIL that subflow before lock_sock; the window is attacker-timed and retryable, not an uninfluencable layout.
PR:N - Completing MP_CAPABLE to an IPPROTO_MPTCP listener needs no account or capability; net.mptcp.enabled defaults to 1 in mptcp pernet init, and tcp_rcv_established/mptcp_incoming_options apply no application credentials before the DATA_ACK and RST/FIN that cause this race.
UI:N - The attacker sends the DATA_ACK and RST/FIN themselves and supplies the request that makes the service call mptcp_sendmsg; no victim mount, click, or extra confirmation is required.
S:U - The divide-error runs in tcp_tso_autosize/tcp_set_skb_tso_segs on the host kernel MPTCP/TCP socket; it does not cross a VM, IOMMU, or sandbox boundary.
C:N - When __tcp_can_send fails in mptcp_sendmsg_frag, info->mss_now stays 0 and tcp_push divides by zero; that CPU exception does not read freed objects or out-of-range kernel memory.
I:N - tcp_write_xmit aborts on the divide in tcp_tso_autosize/tcp_set_skb_tso_segs before modifying TCP control blocks or packet contents; this is not an OOB/UAF write or control-flow hijack.
A:H - bytes/mss_now in tcp_tso_autosize and DIV_ROUND_UP(skb->len, mss_now) in tcp_set_skb_tso_segs raise a kernel divide-error oops/panic from mptcp_push_release, and the attacker can repeat it across MPTCP connections.
CVSS 3.1