The function compat_getdelim_ is used for tor_getline if tor is compiled
on a system that lacks getline and getdelim. These systems should be
very rare, considering that getdelim is POSIX.
If this system is further a 32 bit architecture, it is possible to
trigger a double free with huge files.
If bufsiz has been already increased to 2 GB, the next chunk would
be 4 GB in size, which wraps around to 0 due to 32 bit limitations.
A realloc(*buf, 0) could be imagined as "free(*buf); return malloc(0);"
which therefore could return NULL. The code in question considers
that an error, but will keep the value of *buf pointing to already
freed memory.
The caller of tor_getline() would free the pointer again, therefore
leading to a double free.
This code can only be triggered in dirserv_read_measured_bandwidths
with a huge measured bandwith list file on a system that actually
allows to reach 2 GB of space through realloc.
It is not possible to trigger this on Linux with glibc or other major
*BSD systems even on unit tests, because these systems cannot reach
so much memory due to memory fragmentation.
This patch is effectively based on the penetration test report of
cure53 for curl available at https://cure53.de/pentest-report_curl.pdf
and explained under section "CRL-01-007 Double-free in aprintf() via
unsafe size_t multiplication (Medium)".
Nick Mathewson [Mon, 8 Apr 2019 21:02:14 +0000 (17:02 -0400)]
Detect and suppress an additional gmtime() warning in test_util.c
Fixes bug 29922; bugfix on 0.2.9.3-alpha when we tried to capture
all these warnings. No need to backport any farther than 0.3.5,
though -- these warnings don't cause test failures before then.
This one was tricky to find because apparently it only happened on
_some_ windows builds.
Nick Mathewson [Thu, 4 Apr 2019 15:24:55 +0000 (11:24 -0400)]
Do not cache bogus results from classifying client ciphers
When classifying a client's selection of TLS ciphers, if the client
ciphers are not yet available, do not cache the result. Previously,
we had cached the unavailability of the cipher list and never looked
again, which in turn led us to assume that the client only supported
the ancient V1 link protocol. This, in turn, was causing Stem
integration tests to stall in some cases. Fixes bug 30021; bugfix
on 0.2.4.8-alpha.
juga0 [Tue, 19 Mar 2019 11:48:42 +0000 (11:48 +0000)]
bwauth: Ignore bandwidth file lines with "vote=0"
so that the relays that would be "excluded" from the bandwidth
file because of something failed can be included to diagnose what
failed, without still including these relays in the bandwidth
authorities vote.
Alexander Færøy [Wed, 20 Mar 2019 14:44:06 +0000 (15:44 +0100)]
Handle errors from coveralls more gracefully.
Since we have moved coveralls to the script target the entire build will
now fail if coveralls fail. We handle it more gracefully by echo'ing the
failure instead of doing a hard-failure.
Mike Perry [Mon, 16 Apr 2018 22:49:27 +0000 (22:49 +0000)]
Bug 25733: Avoid assert failure if all circuits time out.
Prior to #23100, we were not counting HS circuit build times in our
calculation of the timeout. This could lead to a condition where our timeout
was set too low, based on non HS circuit build times, and then we would
abandon all HS circuits, storing no valid timeouts in the histogram.
teor [Wed, 27 Feb 2019 06:11:47 +0000 (16:11 +1000)]
appveyor: skip two redundant builds to speed up CI on Windows
Skip the Appveyor 32-bit Windows Server 2016 job, and 64-bit Windows
Server 2012 R2 job. The remaining 2 jobs still provide coverage of
64/32-bit, and Windows Server 2016/2012 R2.
Also set fast_finish, so failed jobs terminate the build immediately.
Nick Mathewson [Tue, 19 Feb 2019 19:02:32 +0000 (14:02 -0500)]
Downgrade some LOG_ERR messages in the address/* tests to warnings
Fixes bug 29530, where the LOG_ERR messages were occurring when
we had no configured network, and so we were failing the unit tests
because of the recently-merged #28668.
Commit message edited by teor:
We backported 28668 and released it in 0.3.5.8.
This commit backports 29530 to 0.3.5.
David Goulet [Thu, 24 Jan 2019 15:52:08 +0000 (10:52 -0500)]
kist: Don't write above the highwater outbuf mark
KIST works by computing how much should be allowed to write to the kernel for
a given socket, and then it writes that amount to the outbuf.
The problem is that it could be possible that the outbuf already has lots of
data in it from a previous scheduling round (because the kernel is full/busy
and Tor was not able to flush the outbuf yet). KIST ignores that the outbuf
has been filling (is above its "highwater") and writes more anyway. The end
result is that the outbuf length would exceed INT_MAX, hence causing an
assertion error and a corresponding "Bug()" message to get printed to the
logs.
This commit makes it for KIST to take into account the outbuf length when
computing the available space.
Bug found and patch by Rob Jansen.
Closes #29168. TROVE-2019-001.
Signed-off-by: David Goulet <dgoulet@torproject.org>
projects / thirdparty / tor.git / log
