[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #22368 [Core Tor/Tor]: double-free of MyFamily lines
#22368: double-free of MyFamily lines
------------------------------------------------+--------------------------
Reporter: arma | Owner:
Type: defect | Status:
| needs_review
Priority: Medium | Milestone: Tor:
| 0.3.1.x-final
Component: Core Tor/Tor | Version: Tor:
| 0.3.1.1-alpha
Severity: Normal | Resolution:
Keywords: regression memory-safety tor-relay | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
------------------------------------------------+--------------------------
Comment (by arma):
Replying to [ticket:22368 arma]:
> ==33656== Invalid read of size 8
> ==33656== at 0x58E41E1: EVP_MD_CTX_cleanup (in /lib/x86_64-linux-
gnu/libcrypto.so.1.0.0)
>[...]
> Once we've resolved this ticket, we should take a closer look at that
last "Invalid read of size 8" stanza, and open a new ticket for it if
needed.
I think this weird stack trace is a side effect of the bug. I got another
trace, when I was triggering the bug on my relay, that looked like this:
{{{
==35332== Invalid read of size 1
==35332== at 0x198624: is_legal_nickname_or_hexdigest (router.c:3419)
==35332== by 0x19CAFA: router_build_fresh_descriptor (router.c:2296)
==35332== by 0x19CD47: router_rebuild_descriptor (router.c:2445)
==35332== by 0x19CF1E: router_get_my_routerinfo (router.c:2013)
==35332== by 0x19DEF4: check_descriptor_ipaddress_changed
(router.c:2589)
==35332== by 0x1528E1: check_descriptor_callback (main.c:1878)
==35332== by 0x171BFF: periodic_event_dispatch (periodic.c:52)
==35332== by 0x2EA12F: event_process_active_single_queue (in
/home/tord/git/src/or/tor)
==35332== by 0x2EA6FF: event_process_active (in
/home/tord/git/src/or/tor)
==35332== by 0x2EAE63: event_base_loop (in /home/tord/git/src/or/tor)
==35332== by 0x154C81: do_main_loop (main.c:2594)
==35332== by 0x155DA4: tor_main (main.c:3745)
==35332== Address 0x72fd640 is 0 bytes inside a block of size 8 free'd
==35332== at 0x4A06430: free (vg_replace_malloc.c:446)
==35332== by 0x5594E1C: CRYPTO_free (in /usr/lib64/libcrypto.so.1.0.1e)
==35332== by 0x55D17C1: bn_expand2 (in /usr/lib64/libcrypto.so.1.0.1e)
==35332== by 0x55CE702: BN_div (in /usr/lib64/libcrypto.so.1.0.1e)
==35332== by 0x55D42C6: BN_nnmod (in /usr/lib64/libcrypto.so.1.0.1e)
==35332== by 0x55D728E: BN_mod_inverse (in
/usr/lib64/libcrypto.so.1.0.1e)
==35332== by 0x55DE366: BN_MONT_CTX_set (in
/usr/lib64/libcrypto.so.1.0.1e)
==35332== by 0x55DE5AF: BN_MONT_CTX_set_locked (in
/usr/lib64/libcrypto.so.1.0.1e)
==35332== by 0x55EF6FA: ??? (in /usr/lib64/libcrypto.so.1.0.1e)
==35332== by 0x55F1879: int_rsa_verify (in
/usr/lib64/libcrypto.so.1.0.1e)
==35332== by 0x55F1C38: RSA_verify (in /usr/lib64/libcrypto.so.1.0.1e)
==35332== by 0x55F62DB: ??? (in /usr/lib64/libcrypto.so.1.0.1e)
}}}
So I think "once you start freeing memory and then using it again, just
about anything could happen" is the right explanation for that other stack
trace.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/22368#comment:6>
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