[tor-bugs] #22368 [Core Tor/Tor]: double-free of MyFamily lines

[Tor Bug Tracker & Wiki]

#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