Make sure to explicitly set key pointers to NULL following the use
of 'ssh_key_free' throughout bind.c.
Before this change, a double free can happen via 'ssh_bind_free'
as in this example callpath:
// create an ssh_bind
ssh_bind b = ssh_bind_new();
// provide a path to a wrong key-type
ssh_bind_options_set(b, SSH_BIND_OPTIONS_DSAKEY, path_to_rsa_key);
// initialize set key-type
ssh_bind_listen(b);
-> error path "The DSA host key has the wrong type: %d",
ssh_key_free(sshbind->dsa)
-> ssh_key_clean(key) // OK
-> SAFE_FREE(key) // OK, but, sshbind->dsa is *not* set to NULL
// ssh_bind_listen failed, so clean up ssh_bind
ssh_bind_free(b);
-> ssh_key_free(sshbind->dsa) // double-free here
To fix, set pointers to NULL that have been free'd with 'ssh_key_free'.
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
This works same way as ssh_forward_accept() but can return a destination
port of the channel (useful if SSH connection forwarding several TCP/IP
ports).
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
Not 100% satisfied of this patch, but the way libgcrypt handles
threading in 1.6 is not compatible with custom handlers. The
new code basicaly uses pthreads in every case. This will probably
not work on windows.
The ssh_userauth_none() call should already be non-blocking. However
this this function is broken in non-blocking mode. It should reveal the
existing bug.
Fix the setting of 'channel->flags' to use '|='. Before this
change, one bug symptom can be that channels are never fully
free'd via ssh_channel_free, resulting in memory leaks.
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
Ensure to use 'ssh_channel_do_free' in 'ssh_disconnect', when removing and
free'ing up a session's channels. This matches the behavior in 'ssh_free',
and is necessary to fully free any channel which may not have been closed
completely (see usage of flags SSH_CHANNEL_FLAG_CLOSED_REMOTE,
SSH_CHANNEL_FLAG_FREED_LOCAL).
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>