CVE-2011-1097: Buffer Overflow

Wayne Davison and I have identified a memory safety bug in rsync >= 3.0.0, affecting the generator process (receiving side) when incremental recursion is on, --delete is on, and --owner is off. Under these conditions, some of the generator's deletion functions temporarily increment fileextracnt, a global variable that governs the in-memory format of filestructs, and restore the original value on completion. The increment was intended to only affect the temporary file lists used to implement deletion, but it can also affect incremental file-list chunks that happen to be received during a call to one of these functions, which will be created in the wrong format. When the original fileextracnt is restored, the value originally stored in each applicable OPTEXTRA field will show up in the next one as listed in rsync.h.

Most of the fields are opaque data or are validated upon use, so their corruption leads to incorrect results but no danger to rsync itself. However, rsync uses the invariant that the FHLPREV field (applicable when --hard-links is on) forms a linked list of file indices consistent with the FLAGHLINK flags. The movement of the FHLGNUM values (which can be chosen arbitrarily by the sender subject to some constraints) into the FHLPREV field has the potential to break memory safety.

Upstream fix for the 3.0.x branch (sum of three commits): http://gitweb.samba.org/?p=rsync.git;a=commitdiff;h=83b94efa6b60a3ff5eee4c5f7812c617a90a03f6;hp=c8255147b06b74dad940d32f9cef5fbe17595239

Upstream bug report (marked fixed, but a full explanation has not been posted due to the security implications): https://bugzilla.samba.org/showbug.cgi?id=7936

I would appreciate Red Hat's help in getting a CVE and determining the severity of the issue. In my testing, I have been able to make an rsync 3.0.7 generator incur valgrind errors and then segfault (details forthcoming), but we have neither confirmed nor ruled out arbitrary code execution.

— Red Hat