Discussion:
crash in SFtp::MergeAttrs at fi->SetUser (utf8_to_lc(a->owner));
Daniel Fazekas
2013-11-07 14:56:51 UTC
Permalink
Recent versions of LFTP seem to crash regularly when using SFTP, always with a similar looking backtrace along the line of:

OS X, lftp 4.4.10:
strlen ()
DirectedBuffer::PutTranslated (this=0x100405280, buf=0xc <Address 0xc out of bounds>) at buffer.h:179
SFtp::utf8_to_lc (this=0x101800000, s=0xc <Address 0xc out of bounds>) at SFtp.cc:1985
SFtp::MergeAttrs (this=0x101800000, fi=0x100700c40, a=0x1005000c0) at SFtp.cc:2033
SFtp::HandleExpect (this=0x101800000, e=0x100500080) at SFtp.cc:967
SFtp::HandleReplies (this=0x101800000) at SFtp.cc:1103
SFtp::Do (this=0x101800000) at SFtp.cc:95
SMTask::Schedule () at SMTask.cc:258
Job::WaitDone (this=0x100404080) at Job.cc:523
Ref<CmdExec>::operator-> () at Ref.h:569
main (argc=1, argv=0x7fff5fbff970) at lftp.cc:570

Fedora Linux 19, lftp 4.4.9:
__strlen_sse2 () from /lib64/libc.so.6
xstrdup(char const*, int) () from /lib64/liblftp-tasks.so.0
StringPool::Get(char const*) () from /lib64/liblftp-tasks.so.0
FileInfo::SetUser(char const*) () from /lib64/liblftp-tasks.so.0
SFtp::MergeAttrs(FileInfo*, SFtp::FileAttrs const*) () from /usr/lib64/lftp/4.4.9/proto-sftp.so
SFtp::HandleExpect(SFtp::Expect*) () from /usr/lib64/lftp/4.4.9/proto-sftp.so
SFtp::HandleReplies() () from /usr/lib64/lftp/4.4.9/proto-sftp.so
SFtp::Do() () from /usr/lib64/lftp/4.4.9/proto-sftp.so
SMTask::Schedule() () from /lib64/liblftp-tasks.so.0
Job::WaitDone() () from /lib64/liblftp-jobs.so.0
main ()

One way I'm able to reliably crash lftp almost every time is to simply open an sftp server, then execute as the first command:
mget ../crash

(That is, specifying a file name which does not exist. Simply "mget crash" usually causes a crash too, but "mget ../crash" appears to crash more often.)
Very rarely, particularly if I executed other commands before, I get the proper "mget: Access failed: No such file" message.

The crash is always ultimately caused by trying to use a->owner which points to a bogus buffer:
<xstring0> = {buf = 0xc <Address 0xc out of bounds>}, size = 4300210416, len = 1

if(a->flags&SSH_FILEXFER_ATTR_OWNERGROUP)
{
fi->SetUser (utf8_to_lc(a->owner));

a->flags varies between 0x500280 or 0x700180 so the SSH_FILEXFER_ATTR_OWNERGROUP is set.
Yet a->owner's buf points to this bogus 0xC address while a->group is a normal null pointer.

My client platforms are all x86_64 and the sftp servers all run OpenSSH 6.2p2.
Alexander Lukyanov
2013-11-08 05:03:32 UTC
Permalink
Thank you for the report! This patch should fix the problem.
--
Alexander.
Post by Daniel Fazekas
Recent versions of LFTP seem to crash regularly when using SFTP, always
strlen ()
DirectedBuffer::PutTranslated (this=0x100405280, buf=0xc <Address 0xc out
of bounds>) at buffer.h:179
SFtp::utf8_to_lc (this=0x101800000, s=0xc <Address 0xc out of bounds>) at SFtp.cc:1985
SFtp::MergeAttrs (this=0x101800000, fi=0x100700c40, a=0x1005000c0) at SFtp.cc:2033
SFtp::HandleExpect (this=0x101800000, e=0x100500080) at SFtp.cc:967
SFtp::HandleReplies (this=0x101800000) at SFtp.cc:1103
SFtp::Do (this=0x101800000) at SFtp.cc:95
SMTask::Schedule () at SMTask.cc:258
Job::WaitDone (this=0x100404080) at Job.cc:523
Ref<CmdExec>::operator-> () at Ref.h:569
main (argc=1, argv=0x7fff5fbff970) at lftp.cc:570
__strlen_sse2 () from /lib64/libc.so.6
xstrdup(char const*, int) () from /lib64/liblftp-tasks.so.0
StringPool::Get(char const*) () from /lib64/liblftp-tasks.so.0
FileInfo::SetUser(char const*) () from /lib64/liblftp-tasks.so.0
SFtp::MergeAttrs(FileInfo*, SFtp::FileAttrs const*) () from
/usr/lib64/lftp/4.4.9/proto-sftp.so
SFtp::HandleExpect(SFtp::Expect*) () from
/usr/lib64/lftp/4.4.9/proto-sftp.so
SFtp::HandleReplies() () from /usr/lib64/lftp/4.4.9/proto-sftp.so
SFtp::Do() () from /usr/lib64/lftp/4.4.9/proto-sftp.so
SMTask::Schedule() () from /lib64/liblftp-tasks.so.0
Job::WaitDone() () from /lib64/liblftp-jobs.so.0
main ()
One way I'm able to reliably crash lftp almost every time is to simply
mget ../crash
(That is, specifying a file name which does not exist. Simply "mget crash"
usually causes a crash too, but "mget ../crash" appears to crash more
often.)
Very rarely, particularly if I executed other commands before, I get the
proper "mget: Access failed: No such file" message.
The crash is always ultimately caused by trying to use a->owner which
<xstring0> = {buf = 0xc <Address 0xc out of bounds>}, size = 4300210416, len = 1
if(a->flags&SSH_FILEXFER_ATTR_OWNERGROUP)
{
fi->SetUser (utf8_to_lc(a->owner));
a->flags varies between 0x500280 or 0x700180 so the
SSH_FILEXFER_ATTR_OWNERGROUP is set.
Yet a->owner's buf points to this bogus 0xC address while a->group is a
normal null pointer.
My client platforms are all x86_64 and the sftp servers all run OpenSSH 6.2p2.
_______________________________________________
lftp mailing list
http://univ.uniyar.ac.ru/mailman/listinfo/lftp
Daniel Fazekas
2013-11-08 12:00:08 UTC
Permalink
Works fine with the patch.
Thanks!
Post by Alexander Lukyanov
Thank you for the report! This patch should fix the problem.
--
Alexander.
Loading...