[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #32472 [Core Tor/Tor]: buf_flush_to_tls: Non-fatal assertion !(flushlen > *buf_flushlen)

#32472: buf_flush_to_tls: Non-fatal assertion !(flushlen > *buf_flushlen)
---------------------------------------------+-----------------------------
 Reporter:  dgoulet                          |          Owner:  nickm
     Type:  defect                           |         Status:  assigned
 Priority:  Medium                           |      Milestone:  Tor:
                                             |  0.4.3.x-final
Component:  Core Tor/Tor                     |        Version:
 Severity:  Normal                           |     Resolution:
 Keywords:  assert, tor-connection 043-must  |  Actual Points:
Parent ID:                                   |         Points:
 Reviewer:                                   |        Sponsor:
---------------------------------------------+-----------------------------

Comment (by nickm):

 Replying to [ticket:32472 dgoulet]:

 > The only thing I can see is if `connection_handle_write_impl()` was
 called with `force = 1` which happens with `connection_flush()` which
 makes tor use the bucket limit instead of the outbuf "flushlen" and thus
 could lead to that assert().

 I think it's `force == 1` that makes us ''not'' use
 `connection_bucket_write_limit()`.  So anyway, let's look more deeply at
 connection_bucket_write_limit, asking: when can it ever return a value
 that is greater than `conn->outbuf_flushlen`?

 Side observation 1: we're being a bit messy with ssize_t versus size_t
 here.  I wonder if that's an issue?  I'm told this is a 64-bit host: if
 so, we can't possibly be overflowing SSIZE_MAX.  But could we be
 underflowing 0?

 The return value from `connection_is_rate_limited()` will come from
 `connection_bucket_get_share()`, called with its `conn_bucket` value no
 greater than outbuf_flushlen.  So let's look at that function, and ask
 whether it can return something greater than `conn_bucket`?

 I think that we maybe can:
 {{{
   if (conn_bucket >= 0 && at_most > conn_bucket)
     at_most = conn_bucket;

   if (at_most < 0)
     return 0;
 }}}

 If `conn_bucket` is negative, then we will not clip at_most to be no more
 than conn_bucket.  Of course, the real `outbuf_flushlen` is unsigned and
 can't be negative, but in principle it _could_ underflow!

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

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs