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
| ||
|
Message-ID: <20170511094758.2112b00f@xeon-e3> Date: Thu, 11 May 2017 09:47:58 -0700 From: Stephen Hemminger <stephen@...workplumber.org> To: Eric Dumazet <edumazet@...gle.com> Cc: netdev@...r.kernel.org Subject: Fw: [Bug 195713] New: TCP recv queue grows huge Begin forwarded message: Date: Thu, 11 May 2017 13:25:23 +0000 From: bugzilla-daemon@...zilla.kernel.org To: stephen@...workplumber.org Subject: [Bug 195713] New: TCP recv queue grows huge https://bugzilla.kernel.org/show_bug.cgi?id=195713 Bug ID: 195713 Summary: TCP recv queue grows huge Product: Networking Version: 2.5 Kernel Version: 3.13.0 4.4.0 4.9.0 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: IPV4 Assignee: stephen@...workplumber.org Reporter: mkm@...to.com Regression: No 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. -- You are receiving this mail because: You are the assignee for the bug.
Powered by blists - more mailing lists