Re: [bug-inetutils] inetutils 1.9.1-4: ftp "get" command occasionally dumps core,

[Mats Erik Andersson]

Dear all,

söndag den  1 september 2013 klockan 14:41 skrev Glenn Golden detta:
> #
> # Mats: This shows only the output starting the fourth "get", which is the one
> # that fails.
> #

Important: it is always the last command that fails in a macro,
and it is always completed. It is the clean-up and return to
command parsing that fails dramatically. This fits well with
the stack contents given below.

I have commented for the record on different aspects of the
back trace report.

Now, however, let us perform an add hoc experiment:

  * Rename the problematic macro "get_files" as "getting".
    Do all your connections again.

The relevant implementation detail is this:

   /* ftp/ftp_var.h *

   struct macel
   {
     char mac_name[9];
     ...
   }

Your string length of "get_files" is already nine, so there
could be a case of off-by-one allocation error lurking here.
That is my best guess at the moment.

I will not be on-line for some days to come, so no commits
or patch suggestions will appear from me. Instead I will
spend time on analysis and test of modifications to "ftp"
that have arisen from this thread.

Best regards,
  Mats E A

> get zziplib-0.13.62-1.src.tar.gz
> 200 PORT command successful. Consider using PASV.
> 150 Opening BINARY mode data connection for zziplib-0.13.62-1.src.tar.gz 
> (686762 bytes).
> ######################################...
> 226 File send OK.
> 686762 bytes received in 13.6 seconds (50607 bytes/s)

Here execution returns from "ftp.c:1091 recvrequest(): return;"
back to "cmds.c:827 getit()". That in turn returns to
"main.c:372 cmdscanner()" from the call "c->c_handler()".

> *** Error in `/home/xxx/src/abs/inetutils/src/inetutils-1.9.1/ftp/ftp': 
> free(): invalid next size (fast): 0x08076388 ***

The block deallocator seems to have gotten its pointer overwritten.
Does access to "line" beyond its allocated space destroy the next-pointer?

> ======= Memory map: ========
> 08048000-08062000 r-xp 00000000 fe:01 84519      
> /home/xxx/src/abs/inetutils/src/inetutils-1.9.1/ftp/ftp
> 08062000-08063000 r--p 00019000 fe:01 84519      
> /home/xxx/src/abs/inetutils/src/inetutils-1.9.1/ftp/ftp
> 08063000-08065000 rw-p 0001a000 fe:01 84519      
> /home/xxx/src/abs/inetutils/src/inetutils-1.9.1/ftp/ftp
> 08065000-0808a000 rw-p 00000000 00:00 0          [heap]

The pointer location 0x08076388 mentioned in error message is in range. 

> #0  0xb7fdd424 in __kernel_vsyscall ()
> #1  0xb7e04256 in raise () from /usr/lib/libc.so.6
> #2  0xb7e059e3 in abort () from /usr/lib/libc.so.6
> #3  0xb7e43625 in __libc_message () from /usr/lib/libc.so.6
> #4  0xb7e4985a in malloc_printerr () from /usr/lib/libc.so.6
> #5  0xb7e4a49c in _int_free () from /usr/lib/libc.so.6

This must be the statement "free(line);". The variable "line"
is only assigned values by readline() or getline(), so I see
no mechanism to corrupt "line" directly. However, "ftp" makes
ample use of setjmp()/longjmp() thereby rewriting the stack
regularly.

> #6  0x08053d12 in cmdscanner (top=1) at main.c:333
> #7  0x08053bc1 in main (argc=1, argv=0xbffff6e8) at main.c:254