This is tracked in H1 as [3636372](https://hackerone.com/reports/3636372). There are two files attached to the submission. One file is called "nullptr-poc.tar.gz" and the other is called "nullptr-poc.mp4". I can look at these files if we think it's worthwhile. CC @dgoulet and @nickm for awareness. Submission content: ## Summary: In core/or/channeltls.c:2054 ``` started_here = chan->conn->handshake_state->started_here; if (chan->conn->base_.state != OR_CONN_STATE_OR_HANDSHAKING_V3) ERR("We're not doing a v3 handshake!"); ``` The snippet of code references the `handshake_state` BEFORE validating the state of the connection. Since `handshake_state` is set to `NULL` after a valid handshake, this enables a null pointer dereference and subsequently crashes the whole tor binary. ## Steps To Reproduce: 1. Open a connection to the target relay / wait for the target client to connect to a malicious relay 2. Perform a normal valid handshake 3. Send any CERT cell ## Supporting Material/References: Attached you find both the reproducible PoC and a video of it working. ## Note on reproducibility: The specific compiler settings used for the official linux x86_64 tor binaries, due to optimizations, swap the check and the dereference in the produced machine code, effectively patching this vulnerability by sheer luck. The vulnerability is still present and reproducible in all tor version i compiled locally, on the official windows x86_64 binaries, and i believe on the official arm and android binaries too. This does NOT mean the linux x86_64 version of tor is not affected, as the compiler might revert the optimization in future releases, with different versions and flags. ## Impact An attacker can, with little to no resources, perform a sustained DoS on the whole network. This also facilitates deanonymization by enabling a Sniper Attack on a target service.