[tor-bugs] #28223 [Core Tor/Tor]: Unparseable microdescriptor on public relay

[Tor Bug Tracker & Wiki]

#28223: Unparseable microdescriptor on public relay
-------------------------------------------------+-------------------------
 Reporter:  teor                                 |          Owner:  nickm
     Type:  defect                               |         Status:
                                                 |  accepted
 Priority:  High                                 |      Milestone:  Tor:
                                                 |  0.4.0.x-final
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  040-must, 040-roadmap-proposed,      |  Actual Points:
  regression?, 035-can, postfreeze-ok,           |
  040-deferred-20190220                          |
Parent ID:                                       |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by nickm):

 Okay, let's try to figure this out.  The nuls are on line 16158, between
 the end of one md and the start of the annotations for the next.  There is
 a 41-minute gap between the @last-listed times of the two microdescs.

 The NULs fill the file between position 0d8546 and 0xd9000 inclusive.
 That last figure suggests to me that we're maybe doing an improper seek.

 Looking at the code in microdesc.c, if we're doing an improper seek, I
 suspect the following places:
    * tor_fd_getpos(), which calls lseek to find the current position in
 the file.  This doesn't seem too likely to me, since it happens between
 writing the annotations and writing the descriptor.
    * The call from start_writing_to_file() to tor_fd_seekend().  This
 looks correct to me, alas.
    * The call to for_fd_setpos() in microdesc_cache_rebuild().  I have
 trouble believing this call is the cause of the problem, since it happens
 when we're rebuilding the main cache, and this bug is in the journal.

 Now, here is another thought.  Is this happening as we write to disk, or
 at some earlier phase?  That is, this bug would also make sense if we had
 something padding microdesc bodies with nuls before or after we downloaded
 them.

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