[Bug 3445] ssh -D leaks file descriptors until new connections fail

[bugzilla-daemon at mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=3445

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org

--- Comment #2 from Damien Miller <djm at mindrot.org> ---
I'm not able to replicate this using openssh HEAD (basically 9.0) on
the client and 8.8p1 on the server.

Using:

$ ulimit -n 32 ; ./ssh -vvvFnone -D1080 ::1

to start the SOCKS listener and

$ for x in `seq 1 256` ; do nc -X 5 -x 127.0.0.1:1080 127.0.0.1 22
</dev/null | head -n 1 ; done

To make sure it is disposing of the fds correctly. It seems to be -
there is no accumulation of connections in FIN_WAIT2 from this.

Next, I tested creating more connections than open fds using

$ sh -c 'ulimit -n 16 ; ./ssh -vvvFnone -D1080 ::1'

and running

$ nc -X 5 -x 127.0.0.1:1080 127.0.0.1 22 &

until no more connections were accepted.

At this point, ssh implements an accept hold-off that prevents hard
spinning on accept():

accept: Too many open files
debug3: channel_handler: chan 1: skip for 1 more seconds
debug3: channel_handler: first channel unpauses in 1 seconds
debug1: Connection to port 1080 forwarding to socks port 0 requested.

So it does call accept() at 1 Hz, but it shouldn't (and doesn't in my
tests) use 100% CPU.

To investigate this further, we will need a debug log (ssh -vvv) from
misbehaving client.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.