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

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#33131: Bug: buf->datalen >= 0x7fffffff
--------------------------+------------------------------------
 Reporter:  cypherpunks   |          Owner:  (none)
     Type:  defect        |         Status:  needs_review
 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 nickm):

 Replying to [comment:9 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.

 One possibility if you want to keep the logging is to use log_ratelim(),
 to prevent it from writing the message too often.

 > 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`?

 Ultimately, yes, though I think there are other things that influence it.

 > 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).

 Hm.  I guess this might not be a problem, though I'd be surprised if the
 code as it stands actually could deliver such a high burst.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/33131#comment:11>
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