netdev - Re: [PATCH net-next] tcp: correct the skip logic in tcp_sacktag

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <9c67190f-62c2-4498-937d-5213de1a3fe0@redhat.com>
Date: Thu, 17 Jul 2025 10:24:11 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: Xin Guo <guoxin0309@...il.com>, ncardwell@...gle.com,
 Kuniyuki Iwashima <kuniyu@...gle.com>
Cc: netdev@...r.kernel.org, edumazet@...gle.com, davem@...emloft.net,
 dsahern@...nel.org, kuba@...nel.org
Subject: Re: [PATCH net-next] tcp: correct the skip logic in
 tcp_sacktag_skip()

On 7/13/25 5:22 PM, Xin Guo wrote:
> tcp_sacktag_skip() directly return the input skb only
> if TCP_SKB_CB(skb)->seq>skip_to_seq,
> this is not right, and  the logic should be
> TCP_SKB_CB(skb)->seq>=skip_to_seq, 

Adding Kuniyuki

I'm not sure this statement is actually true. A more clear (and slightly
more descriptive) commit message could help better understanding the
issue. What is the bad behaviour you are observing?

Ideally a packetdrill test case to demonstrate it would help

> for example
> if start_seq is equal to tcp_highest_sack_seq() ,
> the start_seq is equal to seq of skb which is from
> tcp_highest_sack().
> and on the other side ,when
> tcp_highest_sack_seq() < start_seq in
> tcp_sacktag_write_queue(),
> the skb is from tcp_highest_sack() will be ignored
> in tcp_sacktag_skip(), so clean the logic also.
> 
> Fixes: 75c119afe14f ("tcp: implement rb-tree based retransmit queue")

At very least the fixes tag looks wrong, because AFAICS such change did
not modify the behaviour tcp_sacktag_skip.

> Signed-off-by: Xin Guo <guoxin0309@...il.com>

Thanks,

Paolo