netdev - Re: [PATCH net-next v1] tcp: fix tcp_ofo_queue() to avoid including too much DUP SACK range

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANn89iKrwuyN2ixswA-u1AxW=BX8QwWp=WHskCmh_1qye3QvLA@mail.gmail.com>
Date: Wed, 25 Jun 2025 09:03:13 -0700
From: Eric Dumazet <edumazet@...gle.com>
To: "xin.guo" <guoxin0309@...il.com>
Cc: ncardwell@...gle.com, davem@...emloft.net, dsahern@...nel.org, 
	kuba@...nel.org, pabeni@...hat.com, netdev@...r.kernel.org
Subject: Re: [PATCH net-next v1] tcp: fix tcp_ofo_queue() to avoid including
 too much DUP SACK range

On Wed, Jun 25, 2025 at 8:37 AM xin.guo <guoxin0309@...il.com> wrote:
>
> 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 not 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:
> 1. client.43629 > server.8080: Flags [.], seq 501:1001, ack 1325288529,
> win 20000, length 500: HTTP
> 2. server.8080 > client.43629: Flags [.], ack 1, win 65535, options
> [nop,nop,TS val 269383721 ecr 200,nop,nop,sack 1 {501:1001}], length 0
> 3. Iclient.43629 > server.8080: Flags [.], seq 1501:2001,
> ack 1325288529, win 20000, length 500: HTTP
> 4. server.8080 > client.43629: Flags [.], ack 1, win 65535, options
> [nop,nop,TS val 269383721 ecr 200,nop,nop,sack 2 {1501:2001}
> {501:1001}], length 0
> 5. client.43629 > server.8080: Flags [.], seq 1:2001,
> ack 1325288529, win 20000, length 2000: HTTP
> 6. server.8080 > client.43629: Flags [.], ack 2001, win 65535,
> options [nop,nop,TS val 269383722 ecr 200,nop,nop,sack 1 {501:2001}],
> length 0
>
> After this fix, the step6 is as below:
> 6. server.8080 > client.43629: Flags [.], ack 2001, win 65535,
> options [nop,nop,TS val 269383722 ecr 200,nop,nop,sack 1 {501:1001}],
> length 0

I am not convinced this is the expected output ?

If this is a DUP SACK, it should be :

Flags [.], ack 2001, win 65535, ... sack 2 {1501:2001} {501:1001} ....



>
> Signed-off-by: xin.guo <guoxin0309@...il.com>
> ---
> v1: add more information in commit message
> ---
>  net/ipv4/tcp_input.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> index 19a1542883df..f8c62850e9ca 100644
> --- a/net/ipv4/tcp_input.c
> +++ b/net/ipv4/tcp_input.c
> @@ -4846,7 +4846,7 @@ static void tcp_ofo_queue(struct sock *sk)
>                 if (before(TCP_SKB_CB(skb)->seq, dsack_high)) {
>                         __u32 dsack = dsack_high;
>                         if (before(TCP_SKB_CB(skb)->end_seq, dsack_high))
> -                               dsack_high = TCP_SKB_CB(skb)->end_seq;
> +                               dsack = TCP_SKB_CB(skb)->end_seq;
>                         tcp_dsack_extend(sk, TCP_SKB_CB(skb)->seq, dsack);

At a first glance, bug is in tcp_dsack_extend()