Bug 2784 - rsync gives following error: buffer overflow in receive_file_entry
rsync gives following error: buffer overflow in receive_file_entry
Status: CLOSED FIXED
Product: rsync
Classification: Unclassified
Component: core
2.6.3
All All
: P3 major
: ---
Assigned To: Wayne Davison
Rsync QA Contact
:
: 2785 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-06-09 10:33 UTC by Daniel Carnes
Modified: 2006-03-12 02:56 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 Daniel Carnes 2005-06-09 10:33:08 UTC
If I execute the following command: 
rsync -vrptgz --rsh="ssh $BCPSERVER rsync rsyncd --daemon --
config=$RSYNCDCONFIGFILE --port=$RSYNCDPORT" --rsync-path=$RSYNCPATH   
$RSYNCSOURCE $LOGNAME@$BCPSERVER::$RSYNCDESTINATIONMODULE
 
and I have a symbolic link in the directory represented by $RSYNCSOURCE then I 
get the following output:

building file list ...
5 files to consider
overflow: linkname_len=1862797370
ERROR: buffer overflow in receive_file_entry
rsync error: error allocating core memory buffers (code 22) at util.c(126)
rsync: connection unexpectedly closed (4 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(359)


If I add the -l option to the command then rsync seems to complete fine however 
the symbolic links that have the following pattern symlink -> /foo/bar get 
rsynced to symlink -> foo/bar.

I looked at the source and I have found the code that generated the errors that 
I see. below is the code section from flist.c:

#if SUPPORT_LINKS
	if (preserve_links && S_ISLNK(mode)) {
		linkname_len = read_int(f) + 1; /* count the '\0' */
		if (linkname_len <= 0 || linkname_len > MAXPATHLEN) {
			rprintf(FERROR, "overflow: linkname_len=%d\n",
				linkname_len - 1);
			overflow("receive_file_entry");
		}
	}
	else
#endif


I cannot figure out why we are actually executing this section of code if our 
preserve_links && S_ISLNK variables are not set to 1, which I do not see that 
they are given the rsync arguments that we are using.
Comment 1 Daniel Carnes 2005-06-09 11:20:42 UTC
*** Bug 2785 has been marked as a duplicate of this bug. ***
Comment 2 Wayne Davison 2005-06-12 00:13:30 UTC
This sounds like the bytes being transfer are being corrupted between the sender
and the receiver, possibly because your remote-shell transport is not 8-bit
clean.  You can test this using the "savetransfer" program in the support dir of
a modern rsync release.  Just chdir into the support dir, type make, and then
read the savetransfer.c file's opening comments for how to make a copy of the
data that is being sent or received (one copy on the sender, and one on the
receiver) and then diff it for errors.

Your --rsh options are also strange:  you're using a --port option that has no
effect, for instance (because you'r using a remote shell to talk directly to a
freshly-spawned daemon process over stdin/stdout).  The specifying of rsync
options is more appropriately done in the --rsync-path option rather than in the
--rsh option.  For instance, rsync is appending the --server --daemon options
onto the rsync command, so the command you list is running this (this is a
single command):

ssh BCPSERVER rsync rsyncd --daemon --config=FILE --port=PORT BCPSERVER
/PATH/rsync --server --daemon

If you changed the --rsh option to be just "ssh" and changed the --rsync-path
option to be "$RSYNCPATH --config=$RSYNCDCONFIGFILE", it would run something
more like this:

ssh BCPSERVER /PATH/rsync --config=FILE --server --daemon
Comment 3 Daniel Carnes 2005-06-13 10:53:19 UTC
I get the following errors when not using the -rsh= ssh option:
ERROR: buffer overflow in receive_file_entry
rsync error: error allocating core memory buffers (code 22) at util.c(126)
rsync: connection unexpectedly closed (4 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(359)
It appears to have the same problem regardless of the transport layer.
Comment 4 Daniel Carnes 2005-06-13 11:56:05 UTC
disregard my last comment, the code does act as you suggest when not using the 
ssh as the transport layer.  Are there any known work arounds for this behavior?
Comment 5 Daniel Carnes 2005-06-13 13:28:22 UTC
I made additional mods to the way the script uses ssh as the protocl and it 
worked thanks for the help.