tcp: fix tcp_ofo_queue() to avoid including too much DUP SACK range
authorxin.guo <guoxin0309@gmail.com>
Thu, 26 Jun 2025 12:34:19 +0000 (12:34 +0000)
committerJakub Kicinski <kuba@kernel.org>
Fri, 27 Jun 2025 22:35:03 +0000 (15:35 -0700)
commita041f70e573e185d5d5fdbba53f0db2fbe7257ad
tree77b7e1cc1489bce43e2d6483a59a65b640b7ce17
parent680367bc9be929235cb9d972c8614c1fe16fa67a
tcp: fix tcp_ofo_queue() to avoid including too much DUP SACK range

If the new coming segment covers more than one skbs in the ofo queue,
and which seq is equal to rcv_nxt, then the sequence range
that is duplicated will be sent as DUP SACK, the detail as below,
in step6, the {501,2001} range is clearly including too much
DUP SACK range, in violation of RFC 2883 rules.

1. client > server: Flags [.], seq 501:1001, ack 1325288529, win 20000, length 500
2. server > client: Flags [.], ack 1, [nop,nop,sack 1 {501:1001}], length 0
3. client > server: Flags [.], seq 1501:2001, ack 1325288529, win 20000, length 500
4. server > client: Flags [.], ack 1, [nop,nop,sack 2 {1501:2001} {501:1001}], length 0
5. client > server: Flags [.], seq 1:2001, ack 1325288529, win 20000, length 2000
6. server > client: Flags [.], ack 2001, [nop,nop,sack 1 {501:2001}], length 0

After this fix, the final ACK is as below:

6. server > client: Flags [.], ack 2001, options [nop,nop,sack 1 {501:1001}], length 0

[edumazet] added a new packetdrill test in the following patch.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: xin.guo <guoxin0309@gmail.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20250626123420.1933835-2-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
net/ipv4/tcp_input.c