[tor-bugs] #21312 [Obfuscation/Snowflake]: snowflake-client is pegged at 100% cpu

[Tor Bug Tracker & Wiki]

#21312: snowflake-client is pegged at 100% cpu
-----------------------------------+------------------------------
 Reporter:  arlolra                |          Owner:  arlolra
     Type:  defect                 |         Status:  needs_review
 Priority:  High                   |      Milestone:
Component:  Obfuscation/Snowflake  |        Version:
 Severity:  Major                  |     Resolution:
 Keywords:                         |  Actual Points:
Parent ID:                         |         Points:
 Reviewer:                         |        Sponsor:
-----------------------------------+------------------------------
Changes (by dcf):

 * status:  needs_revision => needs_review


Comment:

 Replying to [comment:32 arlolra]:
 > > Here's a server-webrtc segfault from gdb.
 >
 > From the timeline in comment:29, maybe it's a race between the
 datachannel close on the server and reading from the OR (I'm assuming the
 logs never make it because they're async and the segfaults prevents them
 from being written).
 >
 > You can try something like,

 Good call. I tried your idea and added some debugging code to show the
 addresses of the data channel objects; it was definitely crashing while
 trying to dereference a NULL pointer before (notice `0x0` in the output).
 {{{
 2018/03/14 01:00:03 sdp offer successfully received.
 2018/03/14 01:00:03 Generating answer...
 2018/03/14 01:00:03 answering HTTP POST
 2018/03/14 01:00:03 OnDataChannel
 2018/03/14 01:00:03 OnOpen channel
 2018/03/14 01:00:12 OnMessage <--- 543 bytes
 2018/03/14 01:00:12 Write 543 bytes 0xc42000cd20 --> WebRTC
 2018/03/14 01:00:12 OnMessage <--- 543 bytes
 2018/03/14 01:00:13 Write 543 bytes 0xc42000cd20 --> WebRTC
 2018/03/14 01:00:13 OnMessage <--- 543 bytes
 2018/03/14 01:00:13 Write 543 bytes 0xc42000cd20 --> WebRTC
 2018/03/14 01:00:14 Write 543 bytes 0x0 --> WebRTC
 2018/03/14 01:00:22 OnClose channel 0xc42000cfa0
 2018/03/14 01:00:23 OnMessage <--- 543 bytes
 2018/03/14 01:00:23 Write 543 bytes 0xc42000cd20 --> WebRTC
 2018/03/14 01:00:23 OnMessage <--- 543 bytes
 2018/03/14 01:00:24 Write 543 bytes 0xc42000cd20 --> WebRTC
 2018/03/14 01:00:24 OnMessage <--- 543 bytes
 2018/03/14 01:00:24 Write 543 bytes 0xc42000cd20 --> WebRTC
 2018/03/14 01:00:26 Write 543 bytes 0x0 --> WebRTC
 2018/03/14 01:00:33 OnClose channel 0xc42000d0e0
 2018/03/14 01:00:54 OnClose channel 0xc42000cd20
 }}}

 attachment:0001-Call-explicit-frees-in-server-webrtc.2.patch is a revised
 patch.

 I'm guessing that this only narrows the race window, doesn't eliminate it
 completely, because setting a pointer to `nil` and testing it against
 `nil` are probably not atomic. Maybe we'll have to introduce some
 synchronization.

 I suppose that the corresponding patches for client and proxy-go will also
 have the same flaw? Perhaps this is the cause of the short delays that
 cypherpunks saw in comment:26: the proxy-go instances are randomly
 crashing and being restarted. I'll add some logging to them and see if
 that's the case.

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