I was testing how TCP handled advertising reductions of the window sizes especially Window Full events. To create this setup I made a slow TCP receiver and a fast TCP sender. To add some reality to the scenario I simulated 10ms delay on the loopback device using the netem tc module.

Steps to reproduce:
Bevare these steps will use all the memory on your system

1. create latency on loopback
>sudo tc qdisc change dev lo root netem delay 0ms

2. slow tcp receiver:
>nc -l 4242 | pv -L 1k

3. fast tcp sender:
>nc 127.0.0.1 4242 < /dev/zero

What to expect:
It is expected that the TCP recv queue is not groving unbounded e.g. the following output from netstat:

>netstat -an | grep 4242
>tcp   5563486      0 127.0.0.1:4242          127.0.0.1:59113        
>ESTABLISHED
>tcp        0 3415559 127.0.0.1:59113         127.0.0.1:4242         
>ESTABLISHED

What is seen:

The TCP receive queue grows until there is no more memory available on the system.

>netstat -an | grep 4242
>tcp   223786525      0 127.0.0.1:4242          127.0.0.1:59114      
>ESTABLISHED
>tcp        0   4191037 127.0.0.1:59114         127.0.0.1:4242       
>ESTABLISHED

Note: After the TCP recv queue reaches ~ 2^31 bytes netstat reports a 0 which is not correct, it has probably not been created with this bug in mind.

Systems on which the bug reproducible:

  * debian testing, kernel 4.9.0
  * ubuntu 14.04, kernel 3.13.0
  * ubuntu 16.04, kernel 4.4.0

I have not testet on other systems than the above mentioned.