Bug 390 - restore very long file names: dubious code at client/clitar.c line 1084
Summary: restore very long file names: dubious code at client/clitar.c line 1084
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: smbclient (show other bugs)
Version: 3.0.0
Hardware: All Linux
: P3 normal
Target Milestone: none
Assignee: Samba Bugzilla Account
QA Contact:
Depends on:
Reported: 2003-09-02 09:01 UTC by Craig Barratt
Modified: 2005-09-29 08:19 UTC (History)
0 users

See Also:


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

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

        unfixtarname(longname + offset, buffer_p, MIN(TBLOCK, finfo.size), 
        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 (dead mail address) 2005-02-07 09:09:27 UTC
originally against 3.0.0rc2
Comment 2 Gerald (Jerry) Carter (dead mail address) 2005-09-29 08:19:11 UTC
patches welcome.