[tor-bugs] #33131 [Core Tor/Tor]: Bug: buf->datalen >= 0x7fffffff

[Tor Bug Tracker & Wiki]

#33131: Bug: buf->datalen >= 0x7fffffff
--------------------------+------------------------------------
 Reporter:  cypherpunks   |          Owner:  (none)
     Type:  defect        |         Status:  needs_revision
 Priority:  Medium        |      Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |        Version:  Tor: 0.4.2.5
 Severity:  Minor         |     Resolution:
 Keywords:                |  Actual Points:
Parent ID:                |         Points:
 Reviewer:  nickm         |        Sponsor:
--------------------------+------------------------------------

Comment (by cypherpunks):

 Redid the branch a bit. Not sure how to test it.

 Replying to [comment:8 nickm]:

 Yeah, the logging shouldn't be in the final version. It would just help to
 confirm which number is the one that's extremely high: at_most, or
 buf->datalen.

 Logging would definitely be too loud, considering #31036 and #32022.

 (Historical note, this
 [https://gitweb.torproject.org/tor.git/commit/?id=ee5471f9aab55269c8c480f1f90dfeb08803ac15
 particular check] was added in #21369.)

 So the high burst value, which becomes `at_most` later, is set in
 `connection_or_update_token_buckets_helper`. Doesn't it comes from the
 `BandwidthBurst` option, not `BandwidthRate`?

 As long as we add this sanity check, is there a problem with keeping this
 behavior of using that high value from the user's configuration? `at_most`
 serves as an upper bound on what can be read from the socket in one go, so
 it has to be limited by something like `BUF_MAX_LEN`, but the burst limit
 in the token bucket doesn't have to be limited by that. The burst limit
 persists across multiple calls to `connection_handle_read()` (and any
 draining of `inbuf` in between calls).

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