Bug 390 - restore very long file names: dubious code at client/clitar.c line 1084
restore very long file names: dubious code at client/clitar.c line 1084
Status: RESOLVED LATER
Product: Samba 3.0
Classification: Unclassified
Component: smbclient
3.0.0
All Linux
: P3 normal
: none
Assigned To: Samba Bugzilla Account
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2003-09-02 09:01 UTC by Craig Barratt
Modified: 2005-09-29 08:19 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Craig Barratt 2003-09-02 09:01:27 UTC
The get_longfilename() function is called to extract a long (>100 byte)
file name from the tar archive during extract.

If the file name is really long (ie: more than 512 bytes, one tar block),
this loop in client/clitar.c get_longfilename() builds the complete file
name:

    while (left > 0) {
        if (next_block(tarbuf, &buffer_p, tbufsiz) <= 0) {
            DEBUG(0, ("Empty file, short tar file, or read error: %s\n", 
strerror(errno)));
            return(NULL);
        }

        unfixtarname(longname + offset, buffer_p, MIN(TBLOCK, finfo.size), 
first--);
        DEBUG(5, ("UnfixedName: %s, buffer: %s\n", longname, buffer_p));

        offset += TBLOCK;
        left -= TBLOCK;
    }

In particular, the call to unfixtarname() looks dubious for 3 reasons:

 1) "first--" should really be "first" and first should be explicitly set
    to 0 after the call.  Otherwise, if the loop is traversed three times
    (ok, that's a very long path: more than 1024 bytes) then first will
    be non-zero again the third and subsequent times through, and
    unfixtarname() will incorrectly remove a "." if it occurs at
    this point (ie: 1024 bytes into the path).

 2) should MIN(TBLOCK, finfo.size) really be MIN(TBLOCK, left)?  If the
    path length is, eg, 513, then unfixtarname() will be called twice,
    each time with an argument of 512.  That looks like it will overflow
    longname[].  This might be ok since

 3) buffer_p might not be null terminated, and unfixtarname() calls
    safe_strcpy() on it.

I tried to make a test case on WinXP to verify my concerns but couldn't
get past 256 byte paths on NTFS.  I guess I need to setup a test case
with smbd on linux, but I don't have the time right now to set this test
case up.

Apologies in advance for submitting a bug report when I haven't actually
created an example showing the bug...
Comment 1 Gerald (Jerry) Carter 2005-02-07 09:09:27 UTC
originally against 3.0.0rc2
Comment 2 Gerald (Jerry) Carter 2005-09-29 08:19:11 UTC
patches welcome.