From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.netfilter.org (mail.netfilter.org [217.70.190.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 80CDB440A29; Fri, 31 Jul 2026 15:34:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.70.190.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785512068; cv=none; b=uVI2HBAOrjoEj4KsmeBwXps1oN4q/vSx3ZsP0A9GSBkzNJPcxncD5+ttaapbdZB4bOMEihV6VEve93lM5Q3Ap++yAoesr/xrc93vbgZjiJlzK050XD9/4f4lchc0ytEQsiawp+pT0tCld390HDHvZb44EvNb9wJ48UlSNEE32tE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785512068; c=relaxed/simple; bh=JwPjhVTlf9BmQqtm06vIDRQhdT8cum9RlcRD/AQfkNw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=hVBFFL5PkQVSb0Mu+gnuLiy4CtLMtog/AEDADjAJaA340FZFuAS1/3ZxZqYfSct8Ayu76W71D60IB2tsNT0cxvcFRePg1w9iJRr/0UNnqtNBwYyy+yzFTzg26/4hpxFMjeqAnROHRWWRMGokySdnNXoQkIZRp9Pv37vAOs9wK/A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=netfilter.org; spf=pass smtp.mailfrom=netfilter.org; dkim=pass (2048-bit key) header.d=netfilter.org header.i=@netfilter.org header.b=RpUbeQ4g; arc=none smtp.client-ip=217.70.190.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=netfilter.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=netfilter.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=netfilter.org header.i=@netfilter.org header.b="RpUbeQ4g" Received: from localhost.localdomain (mail-agni [217.70.190.124]) by mail.netfilter.org (Postfix) with ESMTPSA id E8788602B0; Fri, 31 Jul 2026 17:34:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netfilter.org; s=2025; t=1785512064; bh=JZCrM4g7FXNM8t4G1b65O16XG/BfXcnmH0+XDQndLrQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RpUbeQ4gmj+C1so4yNTrUlmRGuCtl/Lh39HrR8xa5CA/+5oVZnuun2D+QVPMzy41t dRxzBq6kj2i4Fk4nq6jTRlunOJL0jptYDJLhSNPeyBsNOBTImMGQ8i7vGgvv8Ar/pB 1HNZ/p471LcGY+34Anc0zsYNarPrcQ0YM0D1RtQMGTmIwA//3J0/5VGnn5QVU4cXSx h+3hPi/5P48vs2JqMw8ofdtf5rcBxkRd9fHGgPYdaGTEs+oZwvuMwruKJF0fI4cb16 LaC8mIw75diiXAAgaI2xdjxZIRb15Y8VMJr/DipTXmsrylr/B919GUY2kdUc4tScM7 aGr3rYFWb6X0A== From: Pablo Neira Ayuso To: netfilter-devel@vger.kernel.org Cc: davem@davemloft.net, netdev@vger.kernel.org, kuba@kernel.org, pabeni@redhat.com, edumazet@google.com, fw@strlen.de, horms@kernel.org Subject: [PATCH net-next 9/9] netfilter: conntrack: tcp: use UNACK timeout for non-closing RST packets Date: Fri, 31 Jul 2026 17:34:02 +0200 Message-ID: <20260731153402.851224-10-pablo@netfilter.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260731153402.851224-1-pablo@netfilter.org> References: <20260731153402.851224-1-pablo@netfilter.org> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Minghao Zhang Commit be0502a3f2e9 ("netfilter: conntrack: tcp: only close if RST matches exact sequence") keeps an established conntrack entry in ESTABLISHED when an in-window RST does not match the expected sequence number exactly, so the endpoint can validate the RST with a challenge ACK. The timeout selection nevertheless uses the CLOSE timeout for every RST packet. The bug is that timeout selection is based on the packet type, not on the state transition result: even when RST validation keeps new_state in ESTABLISHED, the timeout is still forced to TCP_CONNTRACK_CLOSE. Linux TCP independently rate limits challenge ACKs per socket. A second non-exact RST can therefore arrive after the first challenge ACK has restored the timeout but before the rate limit expires. The second RST lowers the timeout to 10 seconds again while the endpoint suppresses the second challenge ACK, allowing the conntrack entry to expire while both TCP endpoints remain established. Using the ESTABLISHED timeout for such RSTs would avoid this short expiration window, but it could also retain stale entries for the five-day default because conntrack cannot reliably match the endpoint's exact TCP state. Use the UNACK timeout for RST packets that leave the conntrack entry in TCP_CONNTRACK_ESTABLISHED. Exact-match RSTs and accepted RST packet trains still fall through to timeouts[new_state], which preserves the CLOSE timeout when conntrack accepts the RST as closing the flow. This avoids the aggressive 10-second expiration window for non-exact RSTs while preserving the short timeout for RSTs that conntrack accepts as closing the flow. Suggested-by: Florian Westphal Reported-by: Minghao Zhang Reported-by: Jianjun Chen Signed-off-by: Minghao Zhang Signed-off-by: Pablo Neira Ayuso --- net/netfilter/nf_conntrack_proto_tcp.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/net/netfilter/nf_conntrack_proto_tcp.c b/net/netfilter/nf_conntrack_proto_tcp.c index ceeed3d7fe52..723e946a78f4 100644 --- a/net/netfilter/nf_conntrack_proto_tcp.c +++ b/net/netfilter/nf_conntrack_proto_tcp.c @@ -1281,8 +1281,9 @@ int nf_conntrack_tcp_packet(struct nf_conn *ct, if (ct->proto.tcp.retrans >= tn->tcp_max_retrans && timeouts[new_state] > timeouts[TCP_CONNTRACK_RETRANS]) timeout = timeouts[TCP_CONNTRACK_RETRANS]; - else if (unlikely(index == TCP_RST_SET)) - timeout = timeouts[TCP_CONNTRACK_CLOSE]; + else if (unlikely(index == TCP_RST_SET && + new_state == TCP_CONNTRACK_ESTABLISHED)) + timeout = timeouts[TCP_CONNTRACK_UNACK]; else if ((ct->proto.tcp.seen[0].flags | ct->proto.tcp.seen[1].flags) & IP_CT_TCP_FLAG_DATA_UNACKNOWLEDGED && timeouts[new_state] > timeouts[TCP_CONNTRACK_UNACK]) -- 2.47.3