[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #15901 [Tor]: apparent memory corruption from control channel request processing -- very difficult to isolate
#15901: apparent memory corruption from control channel request processing -- 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.5.12
Resolution: | Keywords:
Actual Points: | Parent ID:
Points: |
---------------------------+--------------------------------
Comment (by starlight):
Should have included these earlier:
The two scripts I run by hand that
appear to trigger the bug:
{{{
nc [scrubbed] 9151 <<EOF
AUTHENTICATE "[scrubbed]"
GETCONF RelayBandwidthRate
GETCONF RelayBandwidthBurst
getinfo ns/id/[scrubbed]
getinfo ns/name/[scurbbed]
QUIT
EOF
:
}}}
{{{
nc [scrubbed] 9151 <<EOF
AUTHENTICATE "[scurbbed]"
getinfo dir/server/authority
QUIT
EOF
:
}}}
The bug seems to show up on the first consensus
download after the above are run manually in
close succession, somewhere between 24 and
48 hours after restarting the relay.
I must also admit that the system where the problem
occurs is non-ECC, so a remote possibility exists
that the cause is some type of physical memory
corruption. However I believe this is unlikely
as the behavior of this issue is highly specific
and somewhat reproducible. If the system were
experiencing random memory corruption one would
expect to see additional failures. The box is
a low-end business-grade Dell with an AMD CPU
and I've never had a Dell that was anything but
rock solid reliable.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/15901#comment:7>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs