[tor-bugs] #15901 [Tor]: apparent memory corruption -- very difficult to isolate

[Tor Bug Tracker & Wiki]

#15901: apparent memory corruption -- very difficult to isolate
---------------------------+--------------------------------
     Reporter:  starlight  |      Owner:
         Type:  defect     |     Status:  closed
     Priority:  critical   |  Milestone:  Tor: 0.2.7.x-final
    Component:  Tor        |    Version:  Tor: 0.2.6.10
   Resolution:  not a bug  |   Keywords:  PostFreeze027
Actual Points:             |  Parent ID:
       Points:             |
---------------------------+--------------------------------
Changes (by starlight):

 * status:  new => closed
 * resolution:   => not a bug


Comment:

 Found the problem.

 Have been viciously bitten by a case of lazy
 stubbornness, which was the refusal to spend
 a few hours updating the disto of the system
 where the Tor daemon runs.  It harbors an
 ancient version of Fedora, and I've been dropping
 in a current kernel and openssl and thinking
 that would be good enough.

 The glibc on this box has an evil `realloc()`
 bug that's so nasty it could never be reliably
 reproduced, was fixed through pure desk-analysis,
 and was never corrected in older Fedora releases:

 Bug 457508 realloc doesn't fully copy the old data

 https://bugzilla.redhat.com/show_bug.cgi?id=457508

 Figured this out after going over all the core
 images and verifying that, a) no the problem has
 absolutely nothing to do with zlib, b) in every
 case it does indeed involve the random corruption
 of precisely eight bytes of data aligned on an
 eight-byte boundary.  Two of the four cores have
 a corruption value of medium-size integers instead
 of duplicated strings from earlier in the consensus
 document, supporting both (a) and (b).

 In addition, the observed 8-byte corruption size
 is exactly the corruption size of that results
 from the `realloc()` bug.

 The function `tor_gzip_uncompress()` starts with
 a 2-to-1 compression ratio guess that should
 instead be 4-to-1 for consensus documents, so every
 time a consensus is downloaded `tor_realloc()` gets
 invoked and thereby `realloc()` is called, enabling
 the potential for the aforementioned critter to raise
 it's ugly antenna.

 It now makes sense that the problem is sensitive
 to how old cached-* files are since the .new
 differential logic impacts the layout of the
 heap.  The `realloc()` bug requires that the
 destination block be in a different heap arena
 than the source block--a scenario requiring
 a good deal of exact arrangement and
 coincidence.

 Also makes sense that running with MEMCHECK
 or ASAN inhibits the issue since glibc
 `realloc()` is overlaid in both cases.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/15901#comment:40>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online