Port Forward Limit?

Damien Miller djm at mindrot.org
Tue Sep 30 14:47:09 EST 2014

On Fri, 26 Sep 2014, Todd Morgan wrote:

> At my company we use port forwarding as an alternative to VPN. In previous
> releases of openssh (pre 6.0) we could run a script and fetch the thousands
> of forwards to our local machine to connect to remote machines. Since
> openssh 6.x, whenever we run the same script we get a bufferoverflow error.
> ----
> debug1: channel 4577: new [port listener]
> debug1: channel 4578: new [client-session]
> debug1: Requesting no-more-sessions at openssh.com
> debug1: Entering interactive session.
> *** buffer overflow detected ***: ssh terminated

I figured this out - there is no actual buffer overflow, but a misguided
FD_SET check misfiring.

Some background. OpenSSH uses select(2) for fd monitoring. Yes, this
is a crappy interface but it is the most portable way to do it and for
the vast majority of use absolutely fine. One of the biggest problems
with select(2) is that the POSIX-specified API limits the number of file
descriptors that can be monitored to FD_SETSIZE (typically 1024).

Many Unix variants, including Linux, several commercial Unix and all
current BSD allow exceeding this limit by manually allocating the
fd_set. OpenSSH has used this for ~15 years.

Recently, we enabled FORTIFY_SOURCE to get some libc/toolchain hardening
checks. It turns out that one of these is a dumb check in the FD_SET
macro that fd < 1024. The check isn't aware of allocated fd_sets or that
no overflow actually happens.


I'm not sure how to disable this check (which is broken) without turning
off the rest of FORTIFY_SOURCE (which gives some good hardening).
Suggestions welcome.

In the meantime, you can disable this check by editing your Makefile (as
generated by configure) and removing the -DFORTIFY_SOURCE option from


More information about the openssh-unix-dev mailing list