[tor-bugs] #24313 [Core Tor/Tor]: Crash: died: Caught signal 11 [crash from rend_consider_services_intro_points]

[Tor Bug Tracker & Wiki]

#24313: Crash: died: Caught signal 11 [crash from
rend_consider_services_intro_points]
--------------------------+------------------------------------
 Reporter:  cypherpunks   |          Owner:  dgoulet
     Type:  defect        |         Status:  accepted
 Priority:  High          |      Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |        Version:  Tor: 0.3.2.4-alpha
 Severity:  Normal        |     Resolution:
 Keywords:  tor-hs        |  Actual Points:
Parent ID:                |         Points:
 Reviewer:                |        Sponsor:
--------------------------+------------------------------------
Changes (by dgoulet):

 * status:  new => accepted
 * keywords:   => tor-hs
 * owner:  (none) => dgoulet


Comment:

 Ok theory I have so far with this.

 I think the problem could be in `remove_invalid_intro_points()`. We have a
 intro point with a `node_t` but no intro circuit, so the behavior is to
 add that node to the `retry_nodes` list.

 Then, just after, it is possible for that intro point to expire which in
 that case, we'll move it to the `expiring_nodes` list and remove it from
 the working intro point list.

 Then, we are unable to launch an intro circuit (see from the log above)
 and we remove it from the intro list (not in there so doesn't do anything)
 and we free() it.

 Next tor main loop (a second after), we go again through
 `remove_invalid_intro_points()` which will free the intro point object in
 the expiring list if no intro circuit (which is the case) leading to a
 double free.

 So far, this is the only thing I got that could explain this stacktrace...
 If I trick tor into going in that path, I get a heap use after free so I
 suspect that is at least an issue to fix.

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