When a spawned process forks, fails, then exits very quickly, (this
typically occurs when exec fails), there is a race condition between the
SIGCHLD handler updating the process_handle's fields, and checking the
process status in those fields. The update can occur before or after the
spawn tests check the process status.
We check whether the process is running or not running (rather than just
checking if it is running) to avoid this issue.
In circuit_build_times_calculate_timeout() in circuitstats.c, avoid dividing
by zero in the pareto calculations.
If either the alpha or p parameters are 0, we would divide by zero, yielding
an infinite result; which would be clamped to INT32_MAX anyway. So rather
than dividing by zero, we just skip the offending calculation(s), and
use INT32_MAX for the result.
Division by zero traps under clang -fsanitize=undefined-trap -fsanitize-undefined-trap-on-error.
Avoid 4 null pointer errors under clang shallow analysis (the default when
building under Xcode) by using tor_assert() to prove that the pointers
aren't null. Resolves issue 13284 via minor code refactoring.
This helps us avoid undefined behavior. It's based on a patch from teor,
except that I wrote a perl script to regenerate the patch:
#!/usr/bin/perl -p -w -i
BEGIN { %vartypes = (); }
if (/^[{}]/) {
%vartypes = ();
}
if (/^ *crypto_int(\d+) +([a-zA-Z_][_a-zA-Z0-9]*)/) {
$vartypes{$2} = $1;
} elsif (/^ *(?:signed +)char +([a-zA-Z_][_a-zA-Z0-9]*)/) {
$vartypes{$1} = '8';
}
# This fixes at most one shift per line. But that's all the code does.
if (/([a-zA-Z_][a-zA-Z_0-9]*) *<< *(\d+)/) {
$v = $1;
if (exists $vartypes{$v}) {
s/$v *<< *(\d+)/SHL$vartypes{$v}($v,$1)/;
}
}
# remove extra parenthesis
s/\(SHL64\((.*)\)\)/SHL64\($1\)/;
s/\(SHL32\((.*)\)\)/SHL32\($1\)/;
s/\(SHL8\((.*)\)\)/SHL8\($1\)/;
There are some loops of the form
for (i=1;i<1;++i) ...
And of course, if the loop index is initialized to 1, it will never
be less than 1, and the loop body will never be executed. This
upsets coverity.
Patch fixes CID 1221543 and 1221542
This bug shouldn't be reachable so long as secret_to_key_len and
secret_to_key_make_specifier stay in sync, but we might screw up
someday.
Found by coverity; this is CID 1241500
Bugfix on ed8f020e205267e6270494634346ab68d830e1d8; bug not in any
released version of Tor. Found by Coverity; this is CID 1239290.
[Yes, I used this commit message before, in 58e813d0fc.
Turns out, that fix wasn't right, since I didn't look up a
screen. :P ]
When size_t is the most memory you can have, make sure that things
referring to real parts of memory are size_t, not uint64_t or off_t.
But not on any released Tor.
Also, use it to generate test vectors, and add those test vectors
to test_crypto.c
This is based on ed25519.py from the ed25519 webpage; the kludgy hacks
are my own.
This implementation allows somebody to add a blinding factor to a
secret key, and a corresponding blinding factor to the public key.
Robert Ransom came up with this idea, I believe. Nick Hopper proved a
scheme like this secure. The bugs are my own.
For proposal 228, we need to cross-certify our identity with our
curve25519 key, so that we can prove at descriptor-generation time
that we own that key. But how can we sign something with a key that
is only for doing Diffie-Hellman? By converting it to the
corresponding ed25519 point.
See the ALL-CAPS warning in the documentation. According to djb
(IIUC), it is safe to use these keys in the ways that ntor and prop228
are using them, but it might not be safe if we start providing crazy
oracle access.
(Unit tests included. What kind of a monster do you take me for?)
This is another case where DJB likes sticking the whole signature
prepended to the message, and I don't think that's the hottest idea.
The unit tests still pass.
