NEWS for rsync 3.0.8 (26 Mar 2011)
Protocol: 30 (unchanged)
Changes since 3.0.7:
- Fixed two buffer-overflow issues: one where a directory path that is
exactly MAXPATHLEN was not handled correctly, and one handling a
--backup-dir that is extra extra large.
- Fixed a data-corruption issue when preserving hard-links without
preserving file ownership, and doing deletions either before or during
the transfer (CVE-2011-1097). This fixes some assert errors in the
hard-linking code, and some potential failed checksums (via -c) that
should have matched.
- Fixed a potential crash when an rsync daemon has a filter/exclude list
and the transfer is using ACLs or xattrs.
- Fixed a hang if a really large file is being processed by an rsync that
can't handle 64-bit numbers. Rsync will now complain about the file
being too big and skip it.
Maintainers, please bump rsync to 3.0.8. If possible, please add STABLEREQ keyword, CC arches and flip the status whiteboard to "stable" after doing the bump.
in the tree now
(In reply to comment #2)
> in the tree now
Arches, please test and mark stable:
Target keywords : "alpha amd64 arm hppa ia64 m68k ppc ppc64 s390 sh sparc x86"
Tested on x86, looks good to go!
amd64 done, thanks Agostino
Stable for HPPA.
x86 stable, thanks Andreas
Tested OK on SPARc, by doing syncs with Portage trees, seems to be OK. Could be stabilised.
Thanks, folks. GLSA request filed.
rsync 3.x before 3.0.8, when certain recursion, deletion, and ownership
options are used, allows remote rsync servers to cause a denial of service
(heap memory corruption and application crash) or possibly execute arbitrary
code via malformed data.
This issue was resolved and addressed in
GLSA 201412-09 at http://security.gentoo.org/glsa/glsa-201412-09.xml
by GLSA coordinator Sean Amoss (ackle).