samba-bugs@samba.org
2006-Mar-31 11:32 UTC
DO NOT REPLY [Bug 3649] New: buffer overflow in receive_file_entry
https://bugzilla.samba.org/show_bug.cgi?id=3649
Summary: buffer overflow in receive_file_entry
Product: rsync
Version: 2.6.0
Platform: Other
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P3
Component: core
AssignedTo: wayned@samba.org
ReportedBy: sambesselink@planet.nl
QAContact: rsync-qa@samba.org
As a gentoo user I use rsync quite a lot, and am generally happy with your
product. Since not so long I've been getting rsync errors when connecting
with
a timeout of 30secs. My internet connection is quite fast, but my laptop HDD is
dead slow. I suspect the time-out was the problem, since changing it to 180s
solved my problems. But I didn't have time to find out about this solution
before today.
Normally I get errors of this kind:
dev-libs/gdome2/
dev-libs/geoip/
dev-libs/gmp/
rsync: connection unexpectedly closed (3412222 bytes read so far)
rsync error: error in rsync protocol data stream (code 12) at
io.c(189)>>> retry ...
>>> Starting retry 1 of 3 with rsync://81.223.20.162/gentoo-portage
>>> checking server timestamp ...
But this problems seems solved by changing my timeout settings.
Now, while I was experimenting with rsync options, trying to solve this problem
this morning I ran into some extreme rsync behaviour that might be interesting
to you developers:
Gentoo-Users: You've hit rsync1.at.gentoo.org/81.223.20.162
receiving file list ...
overflow: flags=0x65 l1=0 l2=1308622849 lastname=media-libs/a52dec
ERROR: buffer overflow in receive_file_entry
rsync error: error allocating core memory buffers (code 22) at
util.c(121)>>> retry ...
>>> Starting retry 2 of 3 with rsync://62.197.40.130/gentoo-portage
>>> checking server timestamp ...
rsync: connection unexpectedly closed (0 bytes read so far)
rsync error: error in rsync protocol data stream (code 12) at
io.c(189)>>> retry ...
>>> Starting retry 3 of 3 with rsync://213.239.215.148/gentoo-portage
>>> checking server timestamp ...
--
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
samba-bugs@samba.org
2006-May-30 19:43 UTC
DO NOT REPLY [Bug 3649] buffer overflow in receive_file_entry
https://bugzilla.samba.org/show_bug.cgi?id=3649
wayned@samba.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
------- Comment #1 from wayned@samba.org 2006-05-30 14:42 MST -------
The overflow error indicates that the data read over the socket for the size of
the filename was somehow invalid (e.g. it might have gotten corrupted in
transit). If you have a reproducable test case, I'd be glad to take a look
at
the bug. If not, there's very little I can do.
--
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
samba-bugs@samba.org
2006-Jun-07 12:26 UTC
DO NOT REPLY [Bug 3649] buffer overflow in receive_file_entry
https://bugzilla.samba.org/show_bug.cgi?id=3649
rsync@ofdan.co.uk changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rsync@ofdan.co.uk
------- Comment #2 from rsync@ofdan.co.uk 2006-06-07 07:25 MST -------
http://lists.samba.org/archive/rsync/2005-April/012104.html(In reply to comment
#1)> The overflow error indicates that the data read over the socket for the
size of
> the filename was somehow invalid (e.g. it might have gotten corrupted in
> transit). If you have a reproducable test case, I'd be glad to take a
look at
> the bug. If not, there's very little I can do.
>
I have recieved a similiar error to the poster.
ERROR: buffer overflow in receive_file_entry
rsync error: error allocating core memory buffers (code 22) at util.c(126)
I also found a similiar error using google.com here..
http://lists.samba.org/archive/rsync/2005-April/012104.html
I have tested 2.6.6 and 2.6.8
This fix is for 2.6.8
The changes I have made to fix my error were in
flist.c (489.c)
static struct file_struct *receive_file_entry(struct file_list *flist, unsigned
short flags, int f)
I changed the following lines:
static char lastname[MAXPATHLEN], *lastdir;
char thisname[MAXPATHLEN];
if (l2 >= MAXPATHLEN - l1) {
to:
static char lastname[BIGPATHBUFLEN], *lastdir;
char thisname[BIGPATHBUFLEN];
if (l2 >= BIGPATHBUFLEN - l1) {
I haven't done full debugged this, but it compiles and runs, and does what I
want so far.
The cause for this, was very long file names.
--
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
samba-bugs at samba.org
2011-Jan-04 00:50 UTC
DO NOT REPLY [Bug 3649] buffer overflow in receive_file_entry
https://bugzilla.samba.org/show_bug.cgi?id=3649
wayned at samba.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |WORKSFORME
------- Comment #3 from wayned at samba.org 2011-01-03 18:50 CST -------
The original error was for an impossibly large filename length, and thus an
indication of a protocol issue. If increasing the receive buffer size to
something bigger makes rsync work, that is an indication that your system files
are buggy, because any string larger than MAXPATHLEN should not be accepted by
things like open().
So, for the issue reported by Daniel, the correct fix is not to change rsync,
but to get the system include files fixed. Failing that, you could kluge a
larger, more correct value for MAXPATHLEN in rsync.h using a combination of
#undef MAXPATHLEN and #define MAXPATHLEN
<some-larger-but-still-supported-by-the-filesystem-functions-buffer-len-value>.
As before, if someone has a reproducible case for an actual protocol error,
please let us know.
--
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.