[Bug 3894] New: SSH unable to open a new channel if the channel open request came right after a channel close request

[bugzilla-daemon at mindrot.org]

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

            Bug ID: 3894
           Summary: SSH unable to open a new channel if the channel open
                    request came right after a channel close request
           Product: Portable OpenSSH
           Version: 10.2p1
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P5
         Component: sshd
          Assignee: unassigned-bugs at mindrot.org
          Reporter: alanthomasmt at gmail.com

Created attachment 3919
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3919&action=edit
This is a test code that could reproduce the above issue. Please set
the MaxSession as 1 in the sshd server.

To simplify the problem, let’s assume sshd is configured to ‘MaxSession
1’. This means only one channel is allowed at a time for an ssh
connection. Opening a second channel while the first one is still
active will result in a failure, as expected.

However, if a channel close request and a second channel open request
arrive back-to-back without much delay, the channel open request will
fail, even though sshd had already processed the channel close request.

>From the openssh code walk, I identified that the
channel_garbage_collect function initiates the cleanup of channels that
are considered dead and decrements the channel count. This function is
called in every iteration of the server_loop.

Ideally, if sshd has initiated a channel close and has received the
channel close reply from the client, it should have called the garbage
collector to clean up the channel.

In an event of high stress, input packets would be buffered. The
server_loop calls the process_buffered_input_packets function to
process these buffered ssh requests. During this processing, the
garbage collector was not called. This means if a channel close and
channel open request are in the buffered queue, the channel count will
not be decremented after the channel close, preventing the new channel
from being opened.

The same issue was observed with higher MaxSession limits with higher
parallel channels as well.

In my opinion, the garbage collector should be called after processing
the channel close request. Delaying it further blocks the channel open
request that is already in the buffered queue.

Also as an aside note, can you please let me know the relevance of the
garbage collector? Can't the channel get cleaned up right after
receiving the final channel close from the client?

Thanks,
Alan

-- 
You are receiving this mail because:
You are watching the assignee of the bug.