CVE-2021-47242

What it actually does

Race condition in MPTCP subflow_error_report() causes soft lockup when mptcp_data_lock is already held by callers such as mptcp_subflow_data_available(), resulting in deadlock on spinlock acquisition.

Why it matters to the business

Networking stack on affected Linux systems can hang indefinitely under MPTCP traffic, causing denial of service, degraded performance, and potential system instability until reboot.

How an attack unfolds

An attacker sends crafted TCP segments that trigger error reporting paths in MPTCP while the socket is already locked from data-ready or receive contexts; the conflicting lock attempt leads to CPU spin and watchdog timeout.

How to fix it

Upgrade Linux kernel to a version containing the fix that moves error reporting to outer lock contexts; for listed packages apply quinn-rs/quinn commit 53830b6b300dc2d65234a9c510103495f4661dc4 or rust-quinn-proto 0.10.5-2 on Debian 13.

How to confirm the fix worked

Confirm kernel or package version matches the fixed release; reproduce MPTCP error paths under load and verify absence of soft lockup watchdog messages in dmesg.

Typical attack path

1. Establish or hijack an MPTCP connection to the target
2. Send data or error-inducing segments that invoke mptcp_subflow_data_available() under held locks
3. Force subflow_error_report() to contend for mptcp_data_lock
4. Trigger soft lockup and system unresponsiveness

How to detect it

Search kernel logs for soft lockup watchdog entries referencing subflow_error_report, _raw_spin_lock_bh, and mptcp functions; inspect MPTCP connection teardown and error report sequences.

What your security team should do

• Prioritize patching MPTCP-enabled kernels and quinn-based deployments within standard change windows
• Monitor for soft lockup reports involving subflow_error_report and mptcp_data_lock
• Disable MPTCP temporarily on high-risk systems if immediate upgrade is not feasible