#30921: hs-v3: Close intro circuits when cleaning up the client descriptor cache --------------------------------+------------------------------------ Reporter: dgoulet | Owner: dgoulet Type: defect | Status: needs_revision Priority: Medium | Milestone: Tor: 0.4.2.x-final Component: Core Tor/Tor | Version: Severity: Normal | Resolution: Keywords: tor-hs, tor-client | Actual Points: 0.1 Parent ID: #28970 | Points: 0.1 Reviewer: asn | Sponsor: Sponsor27-must --------------------------------+------------------------------------
Comment (by dgoulet): Replying to [comment:4 asn]: > Hmm, some questions about this fix: > > - I'm not sure if the identified race condition is the cause of this assert. Looking at #28970, there are two asserts and the second one is on `hs_ident_intro_circ_is_valid()` which imples that the hs_ident exists but is zeroed out. IIUC, this seems to be the reason that we can't find a descriptor here, and not a race condition. I would argue that the "!desc" assert could be caused by what I outlined and fixed in the patch. The "has opened" code path can't return an error so after that assert is hit, we end up trying to send an INTRODUCE1 on the circuit and then you hit the second assert. The reason why the `intro_auth_pk` key is zeroed is because the `setup_intro_circ_auth_key()` failed before it could be filled (by not finding the descriptor). > > - Just noting that `Regardless of the cause of the assert or not, we should always close pending intro circuits when cleaning up a descriptor`, seems like a step backwards from #22893. Am I right to say that we need to do this anyway so that we maintain our current suboptimal design, and there is no way around it as long as we don't do #22893? Yes, in an ideal world, we would implement #22893 definitely. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/30921#comment:5> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs