From nobody Tue Jun 16 12:41:38 2026 Received: from out-174.mta1.migadu.com (out-174.mta1.migadu.com [95.215.58.174]) (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 6E0E03DEAF6 for ; Wed, 22 Apr 2026 12:36:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.174 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776861394; cv=none; b=t+tx4hu6VQoj+mIQ7JFq4Jot1yzDWOmpXOz7KwF1YKsS9tDPgiZt/hAW9UvPytUgR9beNElYlQhF5IVBQNGJVv2iNvScO/Ikt9JRkxBGlscFcFOOjikWYtP/UZ9Eyhg/IEmy63IYPWewS57S5eac25lADK4YrnKoK8MEQaff/Go= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776861394; c=relaxed/simple; bh=9RWUVF9t30DCtCc3PQoNg12mjY31lao951WtO7/ZGck=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=UXlQYYodIMXAw69Rfqa8aXWnuUQWvnatntTJsZ4yNCPJ7vhcOW1i2cTIXKI1D/8kIXq4ApZdPmmvF+2QzTSpOoUZvLnnG7ykE5NyYnOd53dsSWfaH5Ri4dteEpkvbhBRGkI9ZWeNdMBjjclU+GlrqYuQ2g9eDhpAunqjZ5br97k= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=Zqh/RkXi; arc=none smtp.client-ip=95.215.58.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="Zqh/RkXi" X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1776861386; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=upnWS51x8TXsekOIwMtL9/fKEX7rDTpp2wV3il56Nq0=; b=Zqh/RkXijx9tnT4ws+5e/IuLaNKrfwd0pMIVrWnwNNFIADXycvpgZ5XKtPMzdWQ4OWSoal Z5JXBVOutrDpqqUvRo5vETXxytWYqsYUbOpq5HG+3NtVKTzIwbhYtTo7HP6rkuuDti5MP7 GvYPa6HArSL3XhjZPdA+sJKtqQBfnlc= From: Jiayuan Chen To: netdev@vger.kernel.org Cc: Jiayuan Chen , Eric Dumazet , Neal Cardwell , Kuniyuki Iwashima , "David S. Miller" , David Ahern , Jakub Kicinski , Paolo Abeni , Simon Horman , Shuah Khan , linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org Subject: [PATCH net v3 1/2] tcp: send a challenge ACK on SEG.ACK > SND.NXT Date: Wed, 22 Apr 2026 20:35:38 +0800 Message-ID: <20260422123605.320000-2-jiayuan.chen@linux.dev> In-Reply-To: <20260422123605.320000-1-jiayuan.chen@linux.dev> References: <20260422123605.320000-1-jiayuan.chen@linux.dev> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Migadu-Flow: FLOW_OUT Content-Type: text/plain; charset="utf-8" RFC 5961 Section 5.2 validates an incoming segment's ACK value against the range [SND.UNA - MAX.SND.WND, SND.NXT] and states: "All incoming segments whose ACK value doesn't satisfy the above condition MUST be discarded and an ACK sent back." Commit 354e4aa391ed ("tcp: RFC 5961 5.2 Blind Data Injection Attack Mitigation") opted Linux into this mitigation and implements the challenge ACK on the lower side (SEG.ACK < SND.UNA - MAX.SND.WND), but the symmetric upper side (SEG.ACK > SND.NXT) still takes the pre-RFC-5961 path and silently returns SKB_DROP_REASON_TCP_ACK_UNSENT_DATA, even though RFC 793 Section 3.9 (now RFC 9293 Section 3.10.7.4) has always required: "If the ACK acknowledges something not yet sent (SEG.ACK > SND.NXT) then send an ACK, drop the segment, and return." Complete the mitigation by sending a challenge ACK on that branch, reusing the existing tcp_send_challenge_ack() path which already enforces the per-socket RFC 5961 Section 7 rate limit via __tcp_oow_rate_limited(). FLAG_NO_CHALLENGE_ACK is honoured for symmetry with the lower-edge case. Update the existing tcp_ts_recent_invalid_ack.pkt selftest, which drives this exact path, to consume the new challenge ACK. Fixes: 354e4aa391ed ("tcp: RFC 5961 5.2 Blind Data Injection Attack Mitigat= ion") Signed-off-by: Jiayuan Chen Reviewed-by: Eric Dumazet --- net/ipv4/tcp_input.c | 10 +++++++--- .../net/packetdrill/tcp_ts_recent_invalid_ack.pkt | 4 +++- 2 files changed, 10 insertions(+), 4 deletions(-) diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c index 021f745747c5..c2b6f05acdfa 100644 --- a/net/ipv4/tcp_input.c +++ b/net/ipv4/tcp_input.c @@ -4284,11 +4284,15 @@ static int tcp_ack(struct sock *sk, const struct sk= _buff *skb, int flag) goto old_ack; } =20 - /* If the ack includes data we haven't sent yet, discard - * this segment (RFC793 Section 3.9). + /* If the ack includes data we haven't sent yet, drop the + * segment. RFC 793 Section 3.9 and RFC 5961 Section 5.2 + * require us to send an ACK back in that case. */ - if (after(ack, tp->snd_nxt)) + if (after(ack, tp->snd_nxt)) { + if (!(flag & FLAG_NO_CHALLENGE_ACK)) + tcp_send_challenge_ack(sk, false); return -SKB_DROP_REASON_TCP_ACK_UNSENT_DATA; + } =20 if (after(ack, prior_snd_una)) { flag |=3D FLAG_SND_UNA_ADVANCED; diff --git a/tools/testing/selftests/net/packetdrill/tcp_ts_recent_invalid_= ack.pkt b/tools/testing/selftests/net/packetdrill/tcp_ts_recent_invalid_ack= .pkt index 174ce9a1bfc0..ee6baf7c36cf 100644 --- a/tools/testing/selftests/net/packetdrill/tcp_ts_recent_invalid_ack.pkt +++ b/tools/testing/selftests/net/packetdrill/tcp_ts_recent_invalid_ack.pkt @@ -19,7 +19,9 @@ =20 // bad packet with high tsval (its ACK sequence is above our sndnxt) +0 < F. 1:1(0) ack 9999 win 20000 - +// Challenge ACK for SEG.ACK > SND.NXT (RFC 5961 5.2 / RFC 793 3.9). +// ecr=3D200 (not 200000) proves ts_recent was not updated from the bad pa= cket. + +0 > . 1:1(0) ack 1 =20 +0 < . 1:1001(1000) ack 1 win 20000 +0 > . 1:1(0) ack 1001 --=20 2.43.0 From nobody Tue Jun 16 12:41:38 2026 Received: from out-176.mta1.migadu.com (out-176.mta1.migadu.com [95.215.58.176]) (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 474B63DFC84 for ; Wed, 22 Apr 2026 12:36:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.176 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776861410; cv=none; b=kj2GHoh6CPGYQ8V84Bfe7vUBZIlhw/MYM9IKSTpZl8U7vjQHIZfVuQnxFMJKf6Zgc80r9ozhPBSMgdw/pyILMpGLSQxgQwB2B488eYbvYUXSoS7VteNH4JsEimLOz5TD5V4xZ8T2nC37nycTpFc5CH2AKHWv9ZYnrdG0f6GMYFk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776861410; c=relaxed/simple; bh=UmlsK3nX3/45Gag00vmnNqkWEmc23oJzT6WgbnbrVH0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=nG574chUL48UyOl/QD1DtfO+IDN8opGcKbX3M1IBokPHsvqd8mMkIVc63GsjIg6NTJWFVqRqr/MB3rJo7FWY89kcWMSMa0qwjDx7LKf0leYsHg1vCAXUCRDt6fPz4yuq5PtSefNZr/1uBFiCHqOeSpwFd+rx5pVfkz9eU3VNEto= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=r1gM+m4m; arc=none smtp.client-ip=95.215.58.176 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="r1gM+m4m" X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1776861398; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=pM2IjHIbVO6/fYfLnhdC4p1EDvpZh2+saCdt1MD8IdM=; b=r1gM+m4msXumUedGixP1iFrAGozWcRsMnhcJJYsUHFRXCT5VG07QFCNJFjTDRn7MH9DVP/ d7T7u0F/nZ8SogcJO2Ciw/3DQbIumsM2legm1Tpr41EZEPeu/CDlHJMrEOr7Rf/HnlUbNZ djJDLejb9J3tZU8uMJULxQ9LSZi3qqo= From: Jiayuan Chen To: netdev@vger.kernel.org Cc: Jiayuan Chen , Eric Dumazet , Neal Cardwell , Kuniyuki Iwashima , "David S. Miller" , David Ahern , Jakub Kicinski , Paolo Abeni , Simon Horman , Shuah Khan , linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org Subject: [PATCH net v3 2/2] selftests/net: packetdrill: cover RFC 5961 5.2 challenge ACK on both edges Date: Wed, 22 Apr 2026 20:35:39 +0800 Message-ID: <20260422123605.320000-3-jiayuan.chen@linux.dev> In-Reply-To: <20260422123605.320000-1-jiayuan.chen@linux.dev> References: <20260422123605.320000-1-jiayuan.chen@linux.dev> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Migadu-Flow: FLOW_OUT Content-Type: text/plain; charset="utf-8" RFC 5961 Section 5.2 / RFC 793 Section 3.9 require a challenge ACK whenever an incoming SEG.ACK falls outside [SND.UNA - MAX.SND.WND, SND.NXT]. There is currently no packetdrill coverage for either edge. Add tcp_rfc5961_ack-out-of-window.pkt, which in a single passive-open connection exercises: - Upper edge (SEG.ACK > SND.NXT): peer ACKs data that was never sent before the server has transmitted anything. - Lower edge (SEG.ACK < SND.UNA - MAX.SND.WND): after the server has sent 2000 bytes (the peer-advertised rwnd forces two 1000-byte segments, both acknowledged), peer sends an ACK that is older than the acceptable window. Both cases must elicit a challenge ACK . The per-socket RFC 5961 Section 7 rate limit is disabled for the duration of the test so that both challenge ACKs can fire back-to-back. Signed-off-by: Jiayuan Chen Reviewed-by: Eric Dumazet --- .../tcp_rfc5961_ack-out-of-window.pkt | 48 +++++++++++++++++++ 1 file changed, 48 insertions(+) create mode 100644 tools/testing/selftests/net/packetdrill/tcp_rfc5961_ack= -out-of-window.pkt diff --git a/tools/testing/selftests/net/packetdrill/tcp_rfc5961_ack-out-of= -window.pkt b/tools/testing/selftests/net/packetdrill/tcp_rfc5961_ack-out-o= f-window.pkt new file mode 100644 index 000000000000..2776b8728085 --- /dev/null +++ b/tools/testing/selftests/net/packetdrill/tcp_rfc5961_ack-out-of-window= .pkt @@ -0,0 +1,48 @@ +// SPDX-License-Identifier: GPL-2.0 +// +// RFC 5961 Section 5.2 / RFC 793 Section 3.9: an incoming segment's +// ACK value must lie in [SND.UNA - MAX.SND.WND, SND.NXT]; otherwise +// the receiver MUST discard the segment and send a challenge ACK +// back. Exercise both edges of that window in a single connection. + +`./defaults.sh +sysctl -q net.ipv4.tcp_invalid_ratelimit=3D0 +` + + 0 socket(..., SOCK_STREAM, IPPROTO_TCP) =3D 3 + +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) =3D 0 + +0 bind(3, ..., ...) =3D 0 + +0 listen(3, 1) =3D 0 + +// Three-way handshake. Peer advertises rwnd =3D 1000 (no wscale), so +// MAX.SND.WND is tracked as 1000. + +0 < S 0:0(0) win 1000 + +0 > S. 0:0(0) ack 1 <...> ++.1 < . 1:1(0) ack 1 win 1000 + +0 accept(3, ..., ...) =3D 4 + +// ---- Upper edge: SEG.ACK > SND.NXT -------------------------------- +// Server has sent nothing yet, so SND.UNA =3D SND.NXT =3D 1. +// Peer sends a pure ACK with SEG.ACK =3D 2, beyond SND.NXT. + +0 < . 1:1(0) ack 2 win 1000 +// Expect a challenge ACK: . + +0 > . 1:1(0) ack 1 + +// Advance SND.UNA past MAX.SND.WND so that the lower edge becomes +// reachable. Issue two 1-MSS writes so each skb is exactly one MSS +// and PSH is set by tcp_push() at the end of each sendmsg, keeping +// the setup independent of the TSO / tcp_fragment split path. + +0 write(4, ..., 1000) =3D 1000 + +0 > P. 1:1001(1000) ack 1 ++.01 < . 1:1(0) ack 1001 win 1000 + +0 write(4, ..., 1000) =3D 1000 + +0 > P. 1001:2001(1000) ack 1 ++.01 < . 1:1(0) ack 2001 win 1000 +// Now SND.UNA =3D SND.NXT =3D 2001, MAX.SND.WND =3D 1000, bytes_acked =3D= 2000. + +// ---- Lower edge: SEG.ACK < SND.UNA - MAX.SND.WND ------------------ +// SND.UNA - MAX.SND.WND =3D 2001 - 1000 =3D 1001, so SEG.ACK =3D 1000 fal= ls +// below the acceptable range. + +0 < . 1:1(0) ack 1000 win 1000 +// Expect a challenge ACK: . + +0 > . 2001:2001(0) ack 1 --=20 2.43.0