netdev - [BUG] TCP: Duplicate ACK storm after reordering with delayed packet (BBR RTO triggered)

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:
 <DS0PR11MB77685D8DB5CEACC52391D4E6FD3BA@DS0PR11MB7768.namprd11.prod.outlook.com>
Date: Thu, 28 Aug 2025 01:12:43 +0000
From: "Ahmed, Shehab Sarar" <shehaba2@...inois.edu>
To: "netdev@...r.kernel.org" <netdev@...r.kernel.org>
CC: "edumazet@...gle.com" <edumazet@...gle.com>,
        "ncardwell@...gle.com"
	<ncardwell@...gle.com>,
        "kuniyu@...gle.com" <kuniyu@...gle.com>
Subject: [BUG] TCP: Duplicate ACK storm after reordering with delayed packet
 (BBR RTO triggered)

Hello,

I am a PhD student doing research on adversarial testing of different TCP protocols. Recently, I found an interesting behavior of TCP that I am describing below:

The network RTT was high for about a second before it was abruptly reduced. Some packets sent during the high RTT phase experienced long delays in reaching the destination, while later packets, benefiting from the lower RTT, arrived earlier. This out-of-order arrival triggered the receiver to generate duplicate acknowledgments (dup ACKs). Due to the low RTT, these dup ACKs quickly reached the sender. Upon receiving three dup ACKs, the sender initiated a fast retransmission for an earlier packet that was not lost but was simply taking longer to arrive. Interestingly, despite the fast-retransmitted packet experienced a lower RTT, the original delayed packet still arrived first. When the receiver received this packet, it sent an ACK for the next packet in sequence. However, upon later receiving the fast-retransmitted packet, an issue arose in its logic for updating the acknowledgment number. As a result, even after the next expected packet was received, the acknowledgment number was not updated correctly. The receiver continued sending dup ACKs, ultimately forcing the congestion control protocol into the retransmission timeout (RTO) phase.

I experienced this behavior in linux kernel 5.4.230 version and was wondering if the same issue persists in the recent-most kernel. Do you know of any commit that addressed this issue? If not, I am highly enthusiastic to investigate further. My suspicion is that the problem lies in tcp_input.c. I will be eagerly waiting for your reply.

Thanks
Shehab