netdev - Re: [PATCH net] tcp: tcp_acceptable_seq select SND.UNA when SND.WND is 0

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: <d44f79b3-6b3e-4c20-abdf-3e7da73e932f@redhat.com>
Date: Tue, 15 Apr 2025 13:30:15 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: Luiz Carvalho <luizcmpc@...il.com>, netdev@...r.kernel.org
Cc: Eric Dumazet <edumazet@...gle.com>, Neal Cardwell <ncardwell@...gle.com>
Subject: Re: [PATCH net] tcp: tcp_acceptable_seq select SND.UNA when SND.WND
 is 0



On 4/10/25 7:50 PM, Luiz Carvalho wrote:
> The current tcp_acceptable_seq() returns SND.NXT when the available
> window shrinks to less then one scaling factor. This works fine for most
> cases, and seemed to not be a problem until a slight behavior change to
> how tcp_select_window() handles ZeroWindow cases.
> 
> Before commit 8c670bdfa58e ("tcp: correct handling of extreme memory squeeze"),
> a zero window would only be announced when data failed to be consumed,
> and following packets would have non-zero windows despite the receiver
> still not having any available space. After the commit, however, the
> zero window is stored in the socket and the advertised window will be
> zero until the receiver frees up space.
> 
> For tcp_acceptable_seq(), a zero window case will result in SND.NXT
> being sent, but the problem now arises when the receptor validates the
> sequence number in tcp_sequence():
> 
> static enum skb_drop_reason tcp_sequence(const struct tcp_sock *tp,
> 					 u32 seq, u32 end_seq)
> {
> 	// ...
> 	if (after(seq, tp->rcv_nxt + tcp_receive_window(tp)))
> 		return SKB_DROP_REASON_TCP_INVALID_SEQUENCE;
> 	// ...
> }
> 
> Because RCV.WND is now stored in the socket as zero, using SND.NXT will fail
> the INVALID_SEQUENCE check: SEG.SEQ <= RCV.NXT + RCV.WND. A valid ACK is
> dropped by the receiver, correctly, as RFC793 mentions:
> 
> 	There are four cases for the acceptability test for an incoming
>         segment:
> 
> 	Segment Receive  Test
>         Length  Window
>         ------- -------  -------------------------------------------
> 
>            0       0     SEG.SEQ = RCV.NXT
> 
> The ACK will be ignored until tcp_write_wakeup() sends SND.UNA again,
> and the connection continues. If the receptor announces ZeroWindow
> again, the stall could be very long, as was in my case. Found this out
> while giving a shot at bug #213827.

The dropped ack causing the stall is a zero window probe from the sender
right?
Could you please describe the relevant scenario with a pktdrill test?

Thanks!

Paolo