| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
On an hidden service rendezvous circuit, a BEGIN_DIR could be sent
(maliciously) which would trigger a tor_assert() because
connection_edge_process_relay_cell() thought that the circuit is an
or_circuit_t but is an origin circuit in reality.
Fixes #22494
Reported-by: Roger Dingledine <arma@torproject.org>
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|
|
|
|
|
|
|
|
Fixes bug 22490; bugfix on 6a241ff3ffe7dc1 in 0.2.4.6-alpha.
Found by teor using clang-5.0's AddressSanitizer stack-use-after-scope.
|
|
|
|
|
|
Fix for TROVE-2017-001 and bug 21278.
(Note: Instead of handling signed ints "correctly", we keep the old
behavior, except for the part where we would crash with -ftrapv.)
|
|
|
|
|
|
|
|
|
|
|
|
Add a changes file.
|
|
Fixes bug 16248. Patch from cypherpunks. Bugfix on 0.2.0.1-alpha.
|
|
Reverting this in 0.2.6 only -- we're no backporting
seccomp2-loosening fixes to 0.2.6.
This reverts commit 2ec5e24c58a08816ed2f09c8bd6301599bc2f2f7.
|
|
|
|
|
|
This is a backport of 19728 and 19690
|
|
The length of auth_data from an INTRODUCE2 cell is checked when the
auth_type is recognized (1 or 2), but not for any other non-zero
auth_type. Later, auth_data is assumed to have at least
REND_DESC_COOKIE_LEN bytes, leading to a client-triggered out of bounds
read.
Fixed by checking auth_len before comparing the descriptor cookie
against known clients.
Fixes #15823; bugfix on 0.2.1.6-alpha.
|
|
This helps protect against bugs where any part of a buf_t's memory
is passed to a function that expects a NUL-terminated input.
It also closes TROVE-2016-10-001 (aka bug 20384).
|
|
This helps protect against bugs where any part of a buf_t's memory
is passed to a function that expects a NUL-terminated input.
|
|
This helps protect against bugs where any part of a buf_t's memory
is passed to a function that expects a NUL-terminated input.
|
|
|
|
|
|
|
|
In get_token(), we could read one byte past the end of the
region. This is only a big problem in the case where the region
itself is (a) potentially hostile, and (b) not explicitly
nul-terminated.
This patch fixes the underlying bug, and also makes sure that the
one remaining case of not-NUL-terminated potentially hostile data
gets NUL-terminated.
Fix for bug 21018, TROVE-2016-12-002, and CVE-2016-1254
|
|
|
|
|
|
It had been a directory authority since 0.2.1.20.
|
|
The problem is that "q" is always set on the first iteration even
if the question is not a supported question. This set of "q" is
not necessary, and will be handled after exiting the loop if there
if a supported q->type was found.
[Changes file by nickm]
lease enter the commit message for your changes. Lines starting
|
|
|
|
Conflicts:
src/or/config.c
|
|
This new identity key was changed on 18 November 2015.
|
|
|
|
|
|
|
|
|
|
There was a dead check when we made sure that an array member of a
struct was non-NULL. Tor has been doing this check since at least
0.2.3, maybe earlier.
Fixes bug 17781.
|
|
Fixes #17354
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
|
|
|
|
When we ran out of intro points for a hidden service (which could
happen on a newnym), we would change the connection's state back to
"waiting for hidden service descriptor." But this would make an
assertion fail if we went on to call circuit_get_open_circ_or_launch
again.
This fixes bug 16013; I believe the bug was introduced in
38be533c69417aacf28cedec1c3bae808ce29f4, where we made it possible for
circuit_get_open_circ_or_launch() to change the connection's state.
|
|
|
|
When I fixed #11243, I made it so we would take the digest of a
descriptor before tokenizing it, so we could desist from download
attempts if parsing failed. But when I did that, I didn't remove an
assertion that the descriptor began with "onion-key". Usually, this
was enforced by "find_start_of_next_microdescriptor", but when
find_start_of_next_microdescriptor returned NULL, the assertion was
triggered.
Fixes bug 16400. Thanks to torkeln for reporting and
cypherpunks_backup for diagnosing and writing the first fix here.
|
|
|
|
|
|
If crypto_early_init fails, a typo in a return value from tor_init
means that tor_main continues running, rather than returning
an error value.
Fixes bug 16360; bugfix on d3fb846d8c98 in 0.2.5.2-alpha,
introduced when implementing #4900.
Patch by "teor".
|
