[
https://issues.apache.org/jira/browse/SSHD-754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16075341#comment-16075341
]
Eugene Petrenko commented on SSHD-754:
--------------------------------------
It looks like starting from April 2016, plink enables 'simple' mode for SSH. It
was done by commit b22c0b6f3e6f5254270a89f86df3edfc4da829d2
https://git.tartarus.org/?p=simon/putty.git;a=commit;h=b22c0b6f3e6f5254270a89f86df3edfc4da829d2.
Starting from 0.68 it sends 2GB (0x7fffffff) as receive window size. That makes
SSHD library to be vulnerable for OOM.
The simplified STR is as follows. We need a command that returns huge portion
of data, say bigger than heap size. Next, it is only enough to have a client
which is slow to read data (e.g. slow channel), the server will easily queue to
many packets and it will have OOM out of that.
Looks like the org.apache.sshd.common.channel.ChannelOutputStream and similar
classes should take into account not only the window size but also it's own
write queue.
> OOM in sending data for channel
> -------------------------------
>
> Key: SSHD-754
> URL: https://issues.apache.org/jira/browse/SSHD-754
> Project: MINA SSHD
> Issue Type: Bug
> Affects Versions: 1.1.0
> Reporter: Eugene Petrenko
>
> I have an implementation of SSHD server with the library. It sends gigabytes
> (e.g. 5GB) of data as command output.
> Starting from Putty plink 0.68 (also includes plink 0.69) we started to have
> OOM errors. Checking memory dumps shown the most of the memory is consumed
> from the function
> org.apache.sshd.common.session.AbstractSession#writePacket(org.apache.sshd.common.util.buffer.Buffer)
> In the hprof I see thousands of PendingWriteFuture objects (btw, each holds a
> reference to a logger instance). And those objects are only created from this
> function.
> It is clear the session is running through rekey. I see the kexState
> indicating the progress.
> Is there a way to artificially limit the sending queue, no matter if related
> remote window allows sending that enormous amount of data? As of my
> estimation, the window was reported to be around 1.5 GB or more. Maybe, such
> huge window size was caused by an arithmetic overflow that is fixed on
> SSHD-701
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
