There is a double free error caused by attempting to set up a port forward via the interactive command line (~C) in OpenSSH. Setting a local forward (-L) with the listener port greater than 65535, or a remote forward (-R) with the report port greater than 65535 will cause the double free to occur. This does not happen when setup via the command line (e.g. `ssh -L999999:127.0.0.1:22`) On OpenBSD, it seems it will be triggered only some (but most) times, perhaps a race condition of sorts. Reproduction: 1. SSH to a host (any will do) `ssh remotehost` 2. Once connected and at a shell, enter the interactive command line by hitting return and then ~C followed by another return. You should now have the 'ssh> ' prompt present. 3. Enter '-L999999:localhost:22' followed by return On Ubuntu with OpenSSH 5.1p1, this causes the double free and crash immediately. On OpenBSD 4.4 with OpenSSH 5.1, you must quit SSH to cause the crash (next step.) 4. Type 'exit' to kill the SSH connection 5. The double free should be triggered (below is an example on OpenBSD): $ ssh redoubt.local crash@redoubt.local's password: crash@redoubt:~$ crash@redoubt:~$ ssh> -L999999:localhost:22 Bad forwarding specification. crash@redoubt:~$ exit logout ssh in free(): error: chunk is already free Abort trap (core dumped) Below is a stack trace from the debug version of OpenSSH 5.1p1 (Package openssh-client-dbgsym 1:5.1p1-3ubuntu1) on Ubuntu 8.10, with the same trigger: Program received signal SIGABRT, Aborted. [Switching to Thread 0xb7b446d0 (LWP 25884)] 0xb7fa9430 in __kernel_vsyscall () (gdb) bt #0 0xb7fa9430 in __kernel_vsyscall () #1 0xb7b9c880 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0xb7b9e248 in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0xb7bda10d in ?? () from /lib/tls/i686/cmov/libc.so.6 #4 0xb7be03f4 in ?? () from /lib/tls/i686/cmov/libc.so.6 #5 0xb7be2456 in free () from /lib/tls/i686/cmov/libc.so.6 #6 0xb7fda321 in xfree (ptr=0x0) at ../xmalloc.c:81 #7 0xb7fb9bcb in process_escapes (c=0xb8235240, bin=0xb8235280, bout=0xb8235290 , berr=0xb82352a0, buf=0xbf9efda8 "C", len=1) at ../clientloop.c:882 #8 0xb7fba94d in client_simple_escape_filter (c=0x651c, buf=0xbf9efda8 "C", len =1) at ../clientloop.c:1281 #9 0xb7fcc965 in channel_handle_rfd (c=0xb8235240, readset=<value optimized out >, writeset=0xb8234df0) at ../channels.c:1522 #10 0xb7fcce65 in channel_post_open (c=0xb8235240, readset=0xb8233828, writeset= 0xb8234df0) at ../channels.c:1729 #11 0xb7fd0e1b in channel_handler (ftab=0xb7ffd680, readset=0xb8233828, writeset =0xb8234df0) at ../channels.c:1872 #12 0xb7fbb3d8 in client_loop (have_pty=1, escape_char_arg=126, ssh2_chan_id=0) at ../clientloop.c:1430 #13 0xb7fb3dcd in main (ac=0, av=0xbf9f476c) at ../ssh.c:1231 (gdb)
Is this the same as bug #1539 ?
Looks like it probably is - I'll have to test the current source tree or 5.2 once it's out. Sorry for not seeing that bug! *** This bug has been marked as a duplicate of bug 1539 ***
Close bugs fixed/reviewed for openssh-5.2 release