CVE-2021-47590

What it actually does

Deadlock in __mptcp_push_pending() when mptcp_flush_join_list() is invoked under subflow socket lock and subsequently mptcp_sockopt_sync_all() attempts to acquire the same lock.

Why it matters to the business

Systems using MPTCP may experience kernel-level hangs during network send operations, leading to application unresponsiveness, service disruption, and potential need for manual intervention or reboot.

How an attack unfolds

An attacker with ability to trigger MPTCP sendmsg operations (local or via network peer) causes the deadlock path by exercising socket option synchronization concurrently with pending data push, freezing the affected process as shown in the blocked state trace.

How to fix it

Apply the upstream fix that replaces mptcp_flush_join_list with __mptcp_flush_join_list inside __mptcp_push_pending so socket option work is deferred to a workqueue; update to a kernel build containing this change.

How to confirm the fix worked

Confirm the patched kernel source contains the __mptcp_flush_join_list call in __mptcp_push_pending; test by exercising MPTCP send operations under load while monitoring for lock contention or blocked tasks.

Typical attack path

1. Establish or hijack an MPTCP connection
2. Trigger repeated sendmsg calls while socket options are being synchronized
3. Force __mptcp_push_pending to call mptcp_flush_join_list under subflow lock
4. Induce mptcp_sockopt_sync_all to contend for the same lock
5. Resulting deadlock blocks the sending task indefinitely

How to detect it

Inspect kernel logs and task traces for repeated blocked states involving mptcp_sockopt_sync_all and __mptcp_push_pending; correlate with processes performing MPTCP send operations.

What your security team should do

• Prioritize kernel upgrades for any systems enabling MPTCP
• Monitor for upstream stable branch updates containing this deadlock fix
• Limit MPTCP usage to trusted environments until patched kernels are deployed