$ mkdir testä $ sftp localhost Connected to localhost. sftp> cd /tmp/test sftp> cd tes<TAB>[1] 24810 segmentation fault sftp localhost
I reproduce this with sftp-server from openssh 5.9p1 on folder or file with names containing French accents. Compiled with [0]: ./configure \ --prefix=/usr \ --libexecdir=/usr/lib/ssh \ --sysconfdir=/etc/ssh \ --with-privsep-user=nobody \ --with-md5-passwords \ --with-pam \ --with-mantype=man \ --with-xauth=/usr/bin/xauth \ --with-kerberos5=/usr \ --with-ssl-engine \ --with-libedit=/usr/lib \ --disable-strip make When using "sftp-server -l DEBUG3", I get: Mar 17 23:25:43 localhost sftp-server[1495]: debug3: request 97: opendir Mar 17 23:25:43 localhost sftp-server[1495]: opendir "/mnt/data/music/AudioSlave/../Klub des Loosers/" Mar 17 23:25:43 localhost sftp-server[1495]: debug1: request 97: sent handle handle 0 Mar 17 23:25:43 localhost sftp-server[1495]: debug1: request 98: readdir "/mnt/data/music/AudioSlave/../Klub des Loosers/" (handle 0) Mar 17 23:25:43 localhost sftp-server[1495]: debug1: request 98: sent names count 4 Mar 17 23:25:43 localhost sftp-server[1495]: debug1: request 99: readdir "/mnt/data/music/AudioSlave/../Klub des Loosers/" (handle 0) Mar 17 23:25:43 localhost sftp-server[1495]: debug3: request 99: sent status 1 Mar 17 23:25:43 localhost sftp-server[1495]: sent status End of file Mar 17 23:25:43 localhost sftp-server[1495]: debug3: request 100: close handle 0 Mar 17 23:25:43 localhost sftp-server[1495]: closedir "/mnt/data/music/AudioSlave/../Klub des Loosers/" Mar 17 23:25:43 localhost sftp-server[1495]: debug3: request 100: sent status 0 Mar 17 23:25:43 localhost sftp-server[1495]: sent status Success Mar 17 23:25:43 localhost sftp-server[1495]: debug3: request 101: lstat Mar 17 23:25:43 localhost sftp-server[1495]: lstat name "/mnt/data/music/AudioSlave/../Klub des Loosers/2012 - La Fin De L'Esp\303\250ce" Mar 17 23:25:43 localhost sftp-server[1495]: debug1: request 101: sent attrib have 0xf Mar 17 23:25:43 localhost sftp-server[1495]: debug1: read eof Mar 17 23:25:43 localhost sftp-server[1495]: session closed for local user miguel from [192.168.0.6] Mar 17 23:25:43 localhost sshd[1494]: Received disconnect from 192.168.0.6: 11: disconnected by user Mar 17 23:25:43 localhost sshd[1485]: pam_unix_session(sshd:session): session closed for user miguel Then the client crashes with output "segmentation fault". "echo $?" gives "139". [0] http://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/openssh
I can't replicate this on Goobuntu precise: $ cd /tmp $ touch xxxüxxx $ sftp -D /usr/lib/openssh/sftp-server sftp> ls xxx<TAB> (expands to) sftp> ls xxx\303\274xx xxxüxxx sftp> Perhaps it is locale dependent?
The same here: openssh 6.1p1 archlinux 64-bit sftp> ls 1ążźć 2łóę 4źdźbło sftp> cd 2[tab pressed]segmentation fault (core dumped) locale pl_PL.UTF-8 ssh and sshfs wiork fine. Maybe it's locale depend, but openssh should work with every locale properly ;]
I suspect the comment about locale was a suggestion to either try it with a different one or specify what it was so we could try that. anyway: $ mkdir /tmp/testä $ export LOCALE=pl_PL.UTF-8 $ gdb -q ./sftp Reading symbols from /home/dtucker/openssh-6.1p1/sftp...done. (gdb) set args localhost (gdb) run Starting program: /home/dtucker/openssh-6.1p1/sftp localhost Connected to localhost. sftp> cd /tmp/t[TAB] sftp> cd /tmp/test\303\244/ My guess is that it's crashing inside libedit (mine is 2.11-20080614-5 on x64_64). So far, the only reported instances are on Arch. Could you please try repeating the test under GDB as per the above, and if it does crash us "bt" to get a backtrace to see where it's crashing.
Connected to localhost. sftp> cd z[TAB] zdjęcia z aparatu/ zdjęcia/ Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7893460 in wcslen () from /usr/lib/libc.so.6 (gdb) bt #0 0x00007ffff7893460 in wcslen () from /usr/lib/libc.so.6 #1 0x00007ffff7bacb12 in el_winsertstr () from /usr/lib/libedit.so.0 #2 0x00000000004079d5 in ?? () #3 0x00007ffff7bb299e in el_wgets () from /usr/lib/libedit.so.0 #4 0x00007ffff7bc26ed in el_gets () from /usr/lib/libedit.so.0 #5 0x0000000000407d1d in ?? () #6 0x0000000000403257 in ?? () #7 0x00007ffff7818725 in __libc_start_main () from /usr/lib/libc.so.6 #8 0x0000000000403585 in ?? () I've tried build openssh and glibc with -g, but with no success so far. I'll try tomorrow post more detailed backtrace.
I just tried reproducing this with http://www.thrysoee.dk/editline/libedit-20120601-3.0.tar.gz (which according to https://www.archlinux.org/packages/core/x86_64/libedit/ is what Arch is currently using) built locally on both x86_64 and i686 and neither of them exhibited the problem. Which version of Arch do you see it on, and what version of libedit does it have?
x86_64 I'm using the newest version of libedit: core/libedit 20120601_3.0-1
Note that Arch Linux's version of libedit has wide character support enabled [0]. [0]: https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/libedit#n20
I've been able to reproduce the crash with libedit built with wide character support. Backtrace looks like the following when openssh and libedit are built with full debugging symbols. Looks like libedit is calling strlen on a null string: $ gdb -q ./sftp Reading symbols from /home/dtucker/openssh-6.1p1/sftp...done. (gdb) set args localhost (gdb) run Starting program: /home/dtucker/openssh-6.1p1/sftp localhost warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7ffff7ffa000 Connected to gate. sftp> cd /tmp/t #0 0x00007ffff786da10 in wcslen () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007ffff7ba09c0 in el_winsertstr (el=0x623280, s=0x0) at chared.c:615 #2 0x00007ffff7bc1cbe in el_insertstr (el=0x623280, str=0x7fffffffd9f1 <incomplete sequence \303>) at eln.c:370 #3 0x00000000004083d2 in complete_match (el=0x623280, conn=0x6230c0, remote_path=0x62e670 "/tmp/t", file=0x61e783 <argvs.11342+3> "t", remote=1, lastarg=1, quote=0 '\000', terminated=1) at sftp.c:1773 #4 0x000000000040880a in complete (el=0x623280, ch=9) at sftp.c:1852 #5 0x00007ffff7ba96f0 in el_wgets (el=0x623280, nread=0x7fffffffdb34) at read.c:622 #6 0x00007ffff7bc09e5 in el_gets (el=0x623280, nread=0x7fffffffdb34) at eln.c:80 #7 0x0000000000408ded in interactive_loop (conn=0x6230c0, file1=0x0, file2=0x0) at sftp.c:1965 #8 0x0000000000409a49 in main (argc=2, argv=0x7fffffffe568) at sftp.c:2269 (gdb) print s $1 = 0x0 (gdb) frame 2 #2 0x00007ffff7bc1cbe in el_insertstr (el=0x623280, str=0x7fffffffd9f1 <incomplete sequence \303>) at eln.c:370 370 return el_winsertstr(el, ct_decode_string(str, &el->el_lgcyconv)); (gdb) list 365 366 367 int 368 el_insertstr(EditLine *el, const char *str) 369 { 370 return el_winsertstr(el, ct_decode_string(str, &el->el_lgcyconv)); 371 } (gdb) print str $2 = 0x7fffffffd9f1 <incomplete sequence \303> I don't know what's at fault, though.
Looks like the segfault is a (fixed) bug in libedit: https://bugzilla.redhat.com/show_bug.cgi?id=840598 http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libedit/chared.c.diff?r1=1.36&r2=1.37
Created attachment 2285 [details] make sftp just utf-8 aware enough to not crash libedit Please try this patch, which should stop sftp from sending incomplete utf8 characters to libedit.
Created attachment 2286 [details] make sftp just utf-8 aware enough to not crash libedit slightly better patch that checks for errors in mblen
Your patch works here with: Arch Linux x86_64 OpenSSH 6.2p2 Libedit 20120601 No more segfault.
Created attachment 2289 [details] make sftp just utf-8 aware enough to not crash libedit add a check for excessively long characters (shouldn't happen, but ...)
Created attachment 2291 [details] make sftp just utf-8 aware enough to not crash libedit oops, now with actual patch
I confirm patch 2291 prevents segfault for the specified case also with newest libedit: Openssh 6.2p2 + patch "2291" libedit 20130601_3.1 Thanks!
thanks. patch #2291 applied with a small change to prevent signed vs unsigned warnings. it'll be in the 6.3 release.
Set all RESOLVED bugs to CLOSED with release of OpenSSH 7.1