We strongly suspect that bug 40897 was caused by a custom Tor client that
tried to use more than the default number of conflux circuits, for either
performance or traffic analysis defense gains, or both.
This entity hit a safety check on the exit side, which caused a UAF. Our
"belt and suspenders" snapped off, and hit us in the face... again...
Since there are good reasons to try more than 2 conflux legs, and research has
found some traffic analysis benefits with as many as 5, we're going to raise
and parameterize this limit as a form of bug bounty for finding this UAF, so
that this entity can try out a little more confluxing.
This should also make it easier for researchers to try things like gathering
traces with larger amounts of confluxing than normal, to measure real-world
traffic analysis impacts of conflux.
Shine on, you yoloing anonymous diamond. Let us know if you find out anything
interesting!
The hs_metrics_failed_rdv() macro could pass a NULL value for the identity key
when a building circuit would end up in a failure path *before* the "hs_ident"
was able to be set which leading to this assert.
This was introduced in 0.4.8.1-alpha with the addition of rendezvous circuit
failure metrics for the MetricsPort.
This fixes TROVE-2023-006 for which its severity is considered high.
Signed-off-by: David Goulet <dgoulet@torproject.org>
This has been misspelled when using consensus method 31 or later
since 0.4.6.1-alpha. Fixes bug 40869.
This commit is a backport of b9b0abd6c2 to 0.4.8.
This patch causes `tor_compress_is_compression_bomb()` to emit a
warning-level log message that lets us learn the potential ratio of the
input to output buffer sizes. Hopefully, this will give us a bit of a
better idea whether the compression bomb ratio needs some tuning.
See: tpo/core/tor#40739.
This patch removes a call to `tor_assert_nonfatal_unreached()` in
`relay_key_is_unavailable_()` that is only called when Tor is compiled
without relay support.
Unfortunately, the non-fatal assertion causes a BUG log
message to appear for clients when they start up without relay support
for each CPU worker we spawn. This makes it spotting issues during
bootstrap harder particularly for our iOS developers.
Since the call sites to `get_master_identity_key()` handles `NULL`
values already, we do not think this will be an issue later on.
Reported by Benjamin Erhart (@tla) from Guardian Project.
Fixes tpo/core/tor#40848.
When we implemented prop275 in 0.4.8.1-alpha, we changed the
behavior of networkstatus_getinfo_helper_single to omit meaningful
published_on times, replacing them with "2038-01-01". This is
necessary when we're formatting a routerstatus with no additional
info, since routerstatus objects no longer include a published_on.
But in networkstatus_getinfo_by_purpose, we do have a routerinfo
that does have a published_on. This patch uses that information
to report published_on times in our output when we're making a
"virtual" networkstatus for a big file of routerinfo_t objects.
This is mostly important for bridge authorities, since when
they dump a secret list of the bridges, they want to include
published_on times.
Closes#40855. Bugfix on 0.4.8.1-alpha.
Equi-X supports optionally allocating its solver memory using huge
pages, to reduce the virtual memory subsystem overhead required to make
the entire solver buffer live.
Tor doesn't use this feature, since it seems to have no noticeable
performance benefit at this time, but we still included code for it at
compile time. To improve portability, this patch disables huge page
support by default and enables it only in the cmake build system used
for equix benchmarks.
With this patch equix-bench still supports huge pages. Verified using
strace that we're making the hugepage allocation.
There's no fallback for huge pages, so Equi-X initialization will fail
if they are requested and we don't support them for any runtime or
compile-time reason.
Addresses #40843 (NetBSD) but also prevents future porting issues
related to huge pages.
NetBSD includes the idea of a 'maximum protection' per-region,
and an mprotect which exceeds the max protection will be denied.
If we explicitly ask for a maximum which includes execute permission, we
can successfully swap our code buffer's permissions between read-write
and read-execute when each hash program is compiled.
With this patch, the crypto/hashx tests pass on NetBSD 9.
This addresses bug #40844
As suggested by @wiz on #40843, let's add an explicit check to
hashx_vm_alloc_huge() that avoids using a Linux-style default
on NetBSD targets.
This doesn't change the questionable Linux-style default,
but a future patch will disable this code by default so it's not a
portability liability.
(This code is in hashx's VM layer but it's actually only relevant to
equix.)
This addresses bug #40843. Another patch will disable huge pages
by default entirely, but this patch is sufficient to fix the NetBSD
build.
David Goulet
Alexander Færøy
Mike Perry
Tor CI Release
trinity-1686a
Nick Mathewson
Micah Elizabeth Scott