netdev - Re: tcp: socket stuck with zero receive window after SACK

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: <CADVnQy=RRLaTG4t5BqQ1XJskb+oxWe=M_qY0u9rzmXGS1+b7nQ@mail.gmail.com>
Date: Mon, 19 May 2025 10:42:11 -0400
From: Neal Cardwell <ncardwell@...gle.com>
To: Simon Campion <simon.campion@...pl.com>
Cc: netdev@...r.kernel.org, Eric Dumazet <edumazet@...gle.com>, 
	Yuchung Cheng <ycheng@...gle.com>, Kevin Yang <yyd@...gle.com>
Subject: Re: tcp: socket stuck with zero receive window after SACK

On Mon, May 19, 2025 at 9:31 AM Simon Campion <simon.campion@...pl.com> wrote:
>
> Hi all,
>
> We have a TCP socket that's stuck in the following state:
>
> * it SACKed ~40KB of data, but misses 602 bytes at the beginning
> * it has a zero receive window
> * the Recv-Q as reported by ss is 0
>
> Due to the zero window, the kernel drops the missing 602 bytes when
> the peer sends them. So, the socket is stuck indefinitely waiting for
> data it drops when it receives it. Since the Recv-Q as reported by ss
> is 0, we suspect the receive window is not 0 because the owner of the
> socket isn't reading data. Rather, we wonder whether the kernel SACKed
> too much data than it should have, given the receive buffer size, not
> leaving enough space to store the missing bytes when they arrive.
> Could this happen?
>
> We don't have a reproducer for this issue. The socket is still in this
> state, so we're happy to provide more debugging information while we
> have it. This is the first time we've seen this problem.
>
> Here are more details:
>
> # uname -r
> 6.6.83-flatcar

Thanks for the detailed report!

Can you please attach the output of the following command, run on the
same machine (and in the same network namespace) as the socket with
the receive buffer that is almost full:

  nstat -az > /tmp/nstat.txt

This should help us get a better idea about which "prune" methods are
being tried, and which of them are failing to free up enough memory.

Thanks!
neal