[tor-bugs] #15901 [Tor]: apparent memory corruption -- very difficult to isolate
Tor Bug Tracker & Wiki
blackhole at torproject.org
Mon Aug 24 17:22:49 UTC 2015
#15901: apparent memory corruption -- very difficult to isolate
---------------------------+--------------------------------
Reporter: starlight | Owner:
Type: defect | Status: new
Priority: critical | Milestone: Tor: 0.2.7.x-final
Component: Tor | Version: Tor: 0.2.6.10
Resolution: | Keywords:
Actual Points: | Parent ID:
Points: |
---------------------------+--------------------------------
Comment (by someone_else):
Replying to [comment:26 starlight]:
> I don't see it as a zlib bug because it runs fine
> for three weeks before the problem occurs, is
> clearly related to the gradual shifting around
> of heap allocations.
That's rather unlikely. Look at your 'event04_messages.txt'. Tor downloads
the consensus document via '128.31.0.34:9131'. Descriptor
"no3r7DN7eA+Thw8cstgD9CTAyrGV0CRhNjSqR050,Xs" is corrupt. A couple of
minutes later it downloads the consensus from '194.109.206.212:80' and
exactly the same descriptor is corrupted (and so on for the other
directories that are tried). This is not some random heap corruption,
something deterministic is happening with the compressed input document.
Running fine for 3 weeks doesn't mean anything. My theory is that some
very specific and extremely unlikely sequence in the compressed file is
responsible.
> Also different zlibs
> have been in use at the time of the event
> a) 1.2.8 shared library non-LTO,
> b) 1.2.8 static link LTO.
Did you compile all of them yourself?
> I just put up a image where ASAN+UBSAN are
> applied for only the directory/consensus
> logic, but I did not compile ZLIB with
> instrumentation.
If there is a miscompilation of zlib this more than likely won't catch it.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/15901#comment:28>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list