[tor-bugs] #24610 [Core Tor/Tor]: assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed

[Tor Bug Tracker & Wiki]

#24610: assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed
-----------------------------+------------------------------------
 Reporter:  cypherpunks      |          Owner:  (none)
     Type:  defect           |         Status:  new
 Priority:  Medium           |      Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor     |        Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal           |     Resolution:
 Keywords:  prop224, tor-hs  |  Actual Points:
Parent ID:                   |         Points:
 Reviewer:                   |        Sponsor:
-----------------------------+------------------------------------

Comment (by dgoulet):

 Comment from the code:

 {{{
     status = hs_client_refetch_hsdesc(&edge_conn->hs_ident->identity_pk);
     if (BUG(status == HS_CLIENT_FETCH_HAVE_DESC)) {
       /* This case is unique because it can NOT happen in theory. Once we
 get
        * a new descriptor, the HS client subsystem is notified immediately
 and
        * the connections waiting for it are handled which means the state
 will
        * change from renddesc wait state. Log this and continue to next
        * connection. */
       continue;
     }
 }}}

 So, I think it is a wrong logic. Consider the following case:

 Imagine your client has fetched the descriptor for a service and at some
 point, all intro points weren't usable or in other words the intro points
 rotated and the client now has to fetch a new descriptor. Then this
 suspend happens while waiting for the descriptor fetch.

 We come back from suspend, the clock jumps 2000 seconds (33 minutes) and
 `rend_cache_failure_clean_callback()` is called (it is an housekeeping
 function which runs every 30 seconds). It cleans up the intro point
 failure cache (lifetime of entries are 2 minutes). Which means that the
 descriptor we have in the cache now suddenly is considered "usable".

 During that waiting period for the descriptor, a new consensus comes in so
 we have new directory information and we end up in retrying all pending
 SOCKS connection waiting for a descriptor
 `retry_all_socks_conn_waiting_for_desc()` that might have been hold back
 in the first place because we were missing directory information.

 Then, the BUG() is hit if we try a refetch for a service but for which we
 already have a descriptor. And that descriptor became usable after the
 suspend.

 So this means that the `BUG()` should not be there and be considered
 possible to have that situation.

 And extra bonus point, this should actually be a special case that we
 handle for which we try to attach the connection to a circuit instead of
 leaving it in limbo in `RENDDESC_WAIT` state and timing out after 120
 seconds. In short, put the SOCKS conn in circuit wait state and try to
 attach it if we have a usable descriptor.

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