netdev - [PATCH] subflow: relax WARN in subflow_data

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251212095909.2480475-1-evan.li@linux.alibaba.com>
Date: Fri, 12 Dec 2025 17:59:09 +0800
From: evan.li@...ux.alibaba.com
To: matttbe@...nel.org,
	martineau@...nel.org,
	davem@...emloft.net,
	edumazet@...gle.com,
	kuba@...nel.org,
	pabeni@...hat.com,
	horms@...nel.org
Cc: netdev@...r.kernel.org,
	mptcp@...ts.linux.dev,
	linux-kernel@...r.kernel.org,
	Evan Li <evan.li@...ux.alibaba.com>,
	kitta <kitta@...ux.alibaba.com>
Subject: [PATCH] subflow: relax WARN in subflow_data_ready() on teardown races

From: Evan Li <evan.li@...ux.alibaba.com>

A WARN splat in subflow_data_ready() can be triggered when a subflow
enters an unexpected state during connection teardown or cleanup:

WARNING: net/mptcp/subflow.c:1527 at subflow_data_ready+0x38a/0x670

This comes from the following check:

WARN_ON_ONCE(!__mptcp_check_fallback(msk) &&
!subflow->mp_capable &&
!subflow->mp_join &&
!(state & TCPF_CLOSE));

Under fuzzing and other stress scenarios, there are legitimate windows
where this condition can become true without indicating a real bug, for
example:

during connection teardown / fastclose handling
races with subflow destruction
packets arriving after subflow cleanup
when the parent MPTCP socket is being destroyed
After commit ae155060247b ("mptcp: fix duplicate reset on fastclose"),
these edge cases became easier to trigger and the WARN started firing
spuriously, causing noisy reports but no functional issues.

Refine the state check in subflow_data_ready() so that:

if the socket is in a known teardown/cleanup situation
(SOCK_DEAD, zero parent refcnt, or repair/recv-queue handling),
the function simply returns without emitting a warning; and

for other unexpected states, we emit a ratelimited pr_debug() to
aid debugging, instead of a WARN_ON_ONCE() that can panic
fuzzing/CI kernels or flood logs in production.

This suppresses the bogus warning while preserving diagnostics for any
real state machine bugs.

Fixes: ae155060247b ("mptcp: fix duplicate reset on fastclose")
Reported-by: kitta <kitta@...ux.alibaba.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220856
Co-developed-by: kitta <kitta@...ux.alibaba.com>
Signed-off-by: Evan Li <evan.li@...ux.alibaba.com>
---
 net/mptcp/subflow.c | 24 +++++++++++++++++++++---
 1 file changed, 21 insertions(+), 3 deletions(-)

diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c
index 86ce58ae5..01d30679c 100644
--- a/net/mptcp/subflow.c
+++ b/net/mptcp/subflow.c
@@ -1524,9 +1524,27 @@ static void subflow_data_ready(struct sock *sk)
 		return;
 	}
 
-	WARN_ON_ONCE(!__mptcp_check_fallback(msk) && !subflow->mp_capable &&
-		     !subflow->mp_join && !(state & TCPF_CLOSE));
-
+	/* Check if subflow is in a valid state. Skip warning for legitimate edge cases
+	 * such as connection teardown, race conditions, or when parent is being destroyed.
+	 */
+	if (!__mptcp_check_fallback(msk) && !subflow->mp_capable &&
+	    !subflow->mp_join && !(state & TCPF_CLOSE)) {
+	/* Legitimate cases where this can happen:
+	 * 1. During connection teardown
+	 * 2. Race conditions with subflow destruction
+	 * 3. Packets arriving after subflow cleanup
+	 * Log debug info but don't warn loudly in production.
+	 */
+	if (unlikely(tcp_sk(sk)->repair_queue == TCP_RECV_QUEUE ||
+	    sock_flag(sk, SOCK_DEAD) || !refcount_read(&parent->sk_refcnt))) {
+			/* Expected during cleanup, silently return */
+			return;
+	}
+	/* For other cases, still log for debugging but don't WARN */
+	if (net_ratelimit())
+		pr_debug("MPTCP: subflow in unexpected state sk=%p parent=%p state=%u\n",
+			 sk, parent, state);
+	}
 	if (mptcp_subflow_data_available(sk)) {
 		mptcp_data_ready(parent, sk);
 
-- 
2.43.7