#21369: Tor crashes with tor_assertion_failed_() [Assertion buf->datalen < INT_MAX failed in write_to_buf at ../src/or/buffers.c:832] --------------------------+------------------------------------ Reporter: svengo | Owner: nickm Type: defect | Status: needs_review Priority: Very High | Milestone: Tor: 0.3.0.x-final Component: Core Tor/Tor | Version: Tor: 0.2.9.9 Severity: Critical | Resolution: Keywords: 029-backport | Actual Points: Parent ID: | Points: Reviewer: | Sponsor: --------------------------+------------------------------------
Comment (by teor): Replying to [comment:4 nickm]: > How is this Tor configured? Is it a relay, a hidden service, a client? Can you paste the torrc (or as much of it as is not private)? I strongly suspect it's this relay: https://atlas.torproject.org/#details/6DE61A6F72C1E5418A66BFED80DFB63E4C77668F It has a DirPort, and also supports begindir over ORPort. Replying to [comment:3 nickm]: > Also, I sure wish I knew what this function was: > {{{ > Feb 1 16:54:26 arnor Tor-eriador[24009]: Bug: /usr/bin/tor(+0x1081e6) [0x55744380f1e6 > }}} I think connection_dirserv_add_dir_bytes_to_outbuf() is the most likely candidate here. remaining/bytes is a signed integer that could easily go negative if the offset gets out of sync, and then the int64_t/ssize_t/size_t cast would make it a large positive integer (it's on 64-bit, note the x86_64-linux-gnu backtrace line). Every other caller is either irrelevant to a relay, or passes a strlen(), or an existing size_t (ok, they might be corrupted earlier, but that would cause other issues, right?). -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/21369#comment:8> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online _______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs