Bug 7936 - Incremental file-list corruption due to temporary file_extra_cnt increments (CVE-2011-1097)
Incremental file-list corruption due to temporary file_extra_cnt increments (...
Product: rsync
Classification: Unclassified
Component: core
Other Linux
: P3 major
: ---
Assigned To: Wayne Davison
Rsync QA Contact
Depends on:
  Show dependency treegraph
Reported: 2011-01-27 13:09 UTC by Matt McCutchen
Modified: 2011-04-01 01:39 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Matt McCutchen 2011-01-27 13:09:51 UTC
Under circumstances that are not fully understood but appear to be related to the presence of a transfer and a deletion in a previous directory, rsync 3.0.7 sometimes reports a checksum mismatch for files whose contents are in fact identical on source and destination.

Original report by Mikolaj Kucharski:

A minimized test case:

mkdir src src/sub
touch src/1 src/2 src/sub/file
rsync -a src/ dest/
echo data >src/1
rm src/2

rsync -nvi -rc --delete src/ dest/
Comment 1 Wayne Davison 2011-01-27 20:19:17 UTC
Indeed.  Switching from --delete to --del is enough to avoid the issue.  Will investigate.
Comment 2 Wayne Davison 2011-01-27 20:24:34 UTC
Actually, the bug seems to be somewhat random, so the vanishing of the issue with --del was just a random no-show.
Comment 3 Wayne Davison 2011-01-29 01:08:20 UTC
A work-around for this issue is to always use the --owner (-o) option with --delete when using incremental recursion.

I'll work up an actual fix soon.
Comment 4 Wayne Davison 2011-01-30 00:27:59 UTC
This will be fixed in 3.0.8.
Comment 5 Matt McCutchen 2011-04-01 01:39:08 UTC
The underlying bug here has potential security ramifications, so I was holding off on adding the full story until rsync 3.0.8 was released with the fix.  Briefly: if --recursive, --delete, and --hard-links are on and --owner is off, a malicious sender can cause the receiver's hard-link data structures to become corrupted so as to break memory safety.  I've demonstrated that this can lead to heap corruption; arbitrary code execution has been neither confirmed nor ruled out.  (Some sites are claiming arbitrary code execution is known to be possible; that is incorrect, unless they know something I don't.)

You can read more at https://bugzilla.redhat.com/show_bug.cgi?id=675036.  See also the CVE entry at https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1097.