Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:14:28Zhttps://gitlab.torproject.org/legacy/trac/-/issues/23610handle_establish_intro() can mark circuits for close twice2020-06-13T15:14:28Zteorhandle_establish_intro() can mark circuits for close twiceSome of the failure cases in handle_verified_establish_intro_cell() mark the circuit for close. So if handle_establish_intro() tries to mark it for close again, it will trigger a bug warning.
I think this is the only case in the v3 intr...Some of the failure cases in handle_verified_establish_intro_cell() mark the circuit for close. So if handle_establish_intro() tries to mark it for close again, it will trigger a bug warning.
I think this is the only case in the v3 introduce protocol. We should check for cases like this in the v3 rend protocol as well.
```
/* This cell is legit. Take the appropriate actions. */
cell_ok = handle_verified_establish_intro_cell(circ, parsed_cell);
if (cell_ok < 0) {
goto err;
}
log_warn(LD_GENERAL, "Established prop224 intro point on circuit %" PRIu32,
circ->p_circ_id);
/* We are done! */
retval = 0;
goto done;
err:
circuit_mark_for_close(TO_CIRCUIT(circ), END_CIRC_REASON_TORPROTOCOL);
```Tor: 0.3.0.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/23524Avoid crashing when we ask for running bridges, but UseBridges is 02020-06-13T15:22:57ZteorAvoid crashing when we ask for running bridges, but UseBridges is 0Instead, log a bug, and return the obvious answer: "there are no running bridges".Instead, log a bug, and return the obvious answer: "there are no running bridges".Tor: 0.3.0.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/23516entrynodes.c: fix syntax error2020-06-13T15:13:49ZTracentrynodes.c: fix syntax errorThe brackets in entrynode.c's line 2388 are misplaced in this if statement. Let's fix it.
**Trac**:
**Username**: mergeThe brackets in entrynode.c's line 2388 are misplaced in this if statement. Let's fix it.
**Trac**:
**Username**: mergeTor: 0.3.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/23078hs: Forgotten log_warn for prop224 intro point2020-06-13T15:12:12ZDavid Gouletdgoulet@torproject.orghs: Forgotten log_warn for prop224 intro pointTurns out we forgot to remove that log statement from `hs_intropoint.c`:
```
log_warn(LD_GENERAL, "Established prop224 intro point on circuit %" PRIu32,
circ->p_circ_id);
```
It has been reported here: https://lists.torpr...Turns out we forgot to remove that log statement from `hs_intropoint.c`:
```
log_warn(LD_GENERAL, "Established prop224 intro point on circuit %" PRIu32,
circ->p_circ_id);
```
It has been reported here: https://lists.torproject.org/pipermail/tor-relays/2017-August/012689.html
As far as I can tell, it seems the only warning that is misplaced and that one is unneeded.
However, I might want to take the opportunity to change 3 `log_warn()` and put them to protocol warning level instead.
```
log_warn(LD_REND, "Unable to send INTRODUCE2 cell to the service.");
...
log_warn(LD_REND, "Unable to send an INTRODUCE ACK status %d to client.",
status);
...
log_warn(LD_BUG, "Couldn't send INTRO_ESTABLISHED cell.");
```
They've been introduced in `tor-0.3.0.1-alpha` and `tor-0.3.0.2-alpha`.Tor: 0.3.0.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/22838Backport mingw warning fix from 0.3.1.2020-06-13T15:11:21ZNick MathewsonBackport mingw warning fix from 0.3.1.In 19615bce64cd381a925bc3910120ac39ca918e7c I committed a fix for "unused variable" warnings in test_switch_id.
This bug now prevents the mingwcross builders on jenkins from running; I propose that we backport the fix to ~~0.2.4~~ 0.2.8...In 19615bce64cd381a925bc3910120ac39ca918e7c I committed a fix for "unused variable" warnings in test_switch_id.
This bug now prevents the mingwcross builders on jenkins from running; I propose that we backport the fix to ~~0.2.4~~ 0.2.8 and forward so we can have our CI work again.Tor: 0.3.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/22797macOS should use ULIMIT_BUFFER for open files2020-06-13T15:11:03ZteormacOS should use ULIMIT_BUFFER for open filesThe workaround to use OPEN_MAX for open files doesn't subtract ULIMIT_BUFFER from the limit that's used.
This was introduced in tor-0.2.0.10-alpha.The workaround to use OPEN_MAX for open files doesn't subtract ULIMIT_BUFFER from the limit that's used.
This was introduced in tor-0.2.0.10-alpha.Tor: 0.3.0.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/22753Resolve TROVE-2017-006: Regression in guard family avoidance in 0.3.0 series2020-06-13T15:10:53ZNick MathewsonResolve TROVE-2017-006: Regression in guard family avoidance in 0.3.0 seriesIn 0.3.0, when I revised the guard selection code, I got the "don't use your exit as first-hop if even if it's your guard" logic right, but I accidentally omitted "don't use anything in the exit's family as a guard."
The impact here is...In 0.3.0, when I revised the guard selection code, I got the "don't use your exit as first-hop if even if it's your guard" logic right, but I accidentally omitted "don't use anything in the exit's family as a guard."
The impact here is that some circuits will still use a guard on the same circuit as an exit even when the two are in the same family.
(Putting this issue up on the tracker now because knowing about it does not (much) help an attacker exploit it.)
This is TROVE-2017-006 and CVE-2017-0377.Tor: 0.3.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/22508Assertion failure in rotate_x509_certificate_callback()2020-06-13T15:10:02ZDavid Gouletdgoulet@torproject.orgAssertion failure in rotate_x509_certificate_callback()Surely related to #22460.
Normal tor client (not a relay) with version `0.3.1.2-alpha-dev (git-5343d2b03c8158fc)`. Got this two hours after it started:
```
Jun 06 09:06:02.000 [warn] Can't get my x509 link cert.
Jun 06 09:06:02.000 [er...Surely related to #22460.
Normal tor client (not a relay) with version `0.3.1.2-alpha-dev (git-5343d2b03c8158fc)`. Got this two hours after it started:
```
Jun 06 09:06:02.000 [warn] Can't get my x509 link cert.
Jun 06 09:06:02.000 [err] Unable to update Ed25519->TLS link certificate for new TLS context.
Jun 06 09:06:02.000 [err] tor_assertion_failed_(): Bug: src/or/main.c:1611: rotate_x509_certificate_callback: Assertion 0 failed; aborting. (on Tor 0.3.1.2-alpha-dev 5343d2b03c8158fc)
Jun 06 09:06:02.000 [err] Bug: Assertion 0 failed in rotate_x509_certificate_callback at src/or/main.c:1611. Stack trace: (on Tor 0.3.1.2-alpha-dev 5343d2b03c8158fc)
Jun 06 09:06:02.000 [err] Bug: tor(log_backtrace+0x44) [0x557794125024] (on Tor 0.3.1.2-alpha-dev 5343d2b03c8158fc)
Jun 06 09:06:02.000 [err] Bug: tor(tor_assertion_failed_+0x8d) [0x55779413dfbd] (on Tor 0.3.1.2-alpha-dev 5343d2b03c8158fc)
Jun 06 09:06:02.000 [err] Bug: tor(+0x4ac00) [0x557794004c00] (on Tor 0.3.1.2-alpha-dev 5343d2b03c8158fc)
Jun 06 09:06:02.000 [err] Bug: tor(+0x69590) [0x557794023590] (on Tor 0.3.1.2-alpha-dev 5343d2b03c8158fc)
Jun 06 09:06:02.000 [err] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x6a0) [0x7ff066d47420] (on Tor 0.3.1.2-alpha-dev 5343d2b03c8158fc)
Jun 06 09:06:02.000 [err] Bug: tor(do_main_loop+0x245) [0x557794008345] (on Tor 0.3.1.2-alpha-dev 5343d2b03c8158fc)
Jun 06 09:06:02.000 [err] Bug: tor(tor_main+0x1c35) [0x55779400bd45] (on Tor 0.3.1.2-alpha-dev 5343d2b03c8158fc)
Jun 06 09:06:02.000 [err] Bug: tor(main+0x19) [0x557794003bd9] (on Tor 0.3.1.2-alpha-dev 5343d2b03c8158fc)
Jun 06 09:06:02.000 [err] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7ff065a573f1] (on Tor 0.3.1.2-alpha-dev 5343d2b03c8158fc)
Jun 06 09:06:02.000 [err] Bug: tor(_start+0x2a) [0x557794003c2a] (on Tor 0.3.1.2-alpha-dev 5343d2b03c8158fc)
```Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/22466"Crosscert is expired" warnings: RSA->Ed25519 identity crosscertifice apparen...2020-06-13T15:09:54ZNick Mathewson"Crosscert is expired" warnings: RSA->Ed25519 identity crosscertifice apparently made in 1970?On #22460, we found one mysterious case of link handshake failure: An RSA->Ed25519 identity cross-certificate expiring at Dec 30, 1979. This could likely be caused by passing "0" as the now value in load_ed_keys() : see comment:19:ticke...On #22460, we found one mysterious case of link handshake failure: An RSA->Ed25519 identity cross-certificate expiring at Dec 30, 1979. This could likely be caused by passing "0" as the now value in load_ed_keys() : see comment:19:ticket:22460 .Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/22447hs: HSDir do not accept v3 descriptors properly2020-06-13T15:09:43ZDavid Gouletdgoulet@torproject.orghs: HSDir do not accept v3 descriptors properlyWhen a v3 descriptor is uploaded, it goes through a series of validation including `encrypted_data_length_is_valid()` which checks for the encrypted data size to be a multiple of `#define HS_DESC_PLAINTEXT_PADDING_MULTIPLE 128` but it's ...When a v3 descriptor is uploaded, it goes through a series of validation including `encrypted_data_length_is_valid()` which checks for the encrypted data size to be a multiple of `#define HS_DESC_PLAINTEXT_PADDING_MULTIPLE 128` but it's not true anymore becase we pad up to a minimum of 10000 bytes.
This is currently fixed upstream but wasn't backported to 030. It has been introduced in tor-0.3.0.1-alpha with commit cff1fd63f16.Tor: 0.3.0.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/22325"we're missing descriptors for some of our primary entry guards" while using ...2020-06-13T15:09:14ZNick Mathewson"we're missing descriptors for some of our primary entry guards" while using bridgesOpening this ticket to track the bridge-using case of #21969. Leaving the parent ticket open since there seems to be a case for non-bridge users.Opening this ticket to track the bridge-using case of #21969. Leaving the parent ticket open since there seems to be a case for non-bridge users.Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/22255Frequent OOM kills of tor process2020-06-13T15:19:30ZTracFrequent OOM kills of tor processWe are currently expierencing frequent Out of memory kills of or tor processes on two boxes running ubuntu 14.04.
```
root@tor1:~# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.5 LTS
Relea...We are currently expierencing frequent Out of memory kills of or tor processes on two boxes running ubuntu 14.04.
```
root@tor1:~# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.5 LTS
Release: 14.04
Codename: trusty
```
We experience this on following versions:
0.3.0.5-rc-1~trusty+1 and 0.2.9.10-1~trusty+1
I changed to the rc after the normal 2.9.10-1 Version keept having this problems. The 0.3.0.5-rc has the same problems.
From syslog
```
May 14 10:21:42 tor1 kernel: [123517.565688] UDP: bad checksum. From 82.247.214.125:51413 to 176.10.104.240:21446 ulen 38
May 14 11:02:47 tor1 kernel: [125982.993268] tor invoked oom-killer: gfp_mask=0x200da, order=0, oom_score_adj=0
May 14 11:02:47 tor1 kernel: [125982.993270] tor cpuset=/ mems_allowed=0
May 14 11:02:47 tor1 kernel: [125982.993272] CPU: 2 PID: 33180 Comm: tor Not tainted 3.13.0-117-generic !#164-Ubuntu
May 14 11:02:47 tor1 kernel: [125982.993273] Hardware name: HP ProLiant ML310e Gen8 v2, BIOS P78 03/28/2014
May 14 11:02:47 tor1 kernel: [125982.993274] 0000000000000000 ffff8800a8679990 ffffffff8172d1c9 ffff88013c868000
May 14 11:02:47 tor1 kernel: [125982.993276] 0000000000000000 ffff8800a8679a18 ffffffff81727768 ffffffff8106a926
May 14 11:02:47 tor1 kernel: [125982.993278] ffff8800a86799f0 ffffffff810cb27c 0000000001320122 0000000000000000
May 14 11:02:47 tor1 kernel: [125982.993279] Call Trace:
May 14 11:02:47 tor1 kernel: [125982.993285] [<ffffffff8172d1c9>] dump_stack+0x64/0x82
May 14 11:02:47 tor1 kernel: [125982.993286] [<ffffffff81727768>] dump_header+0x7f/0x1f1
May 14 11:02:47 tor1 kernel: [125982.993289] [<ffffffff8106a926>] ? put_online_cpus+0x56/0x80
May 14 11:02:47 tor1 kernel: [125982.993291] [<ffffffff810cb27c>] ? rcu_oom_notify+0xcc/0xf0
May 14 11:02:47 tor1 kernel: [125982.993294] [<ffffffff81156d81>] oom_kill_process+0x201/0x360
May 14 11:02:47 tor1 kernel: [125982.993297] [<ffffffff812dde35>] ? security_capable_noaudit+0x15/0x20
May 14 11:02:47 tor1 kernel: [125982.993299] [<ffffffff81157511>] out_of_memory+0x471/0x4b0
May 14 11:02:47 tor1 kernel: [125982.993301] [<ffffffff8115d82c>] !__alloc_pages_nodemask+0xa6c/0xb90
May 14 11:02:47 tor1 kernel: [125982.993304] [<ffffffff8119e25a>] alloc_pages_vma+0x9a/0x140
May 14 11:02:47 tor1 kernel: [125982.993307] [<ffffffff811908eb>] read_swap_cache_async+0xeb/0x160
May 14 11:02:47 tor1 kernel: [125982.993308] [<ffffffff811909f8>] swapin_readahead+0x98/0xe0
May 14 11:02:47 tor1 kernel: [125982.993320] [<ffffffff8117e90b>] handle_mm_fault+0xa7b/0xf10
May 14 11:02:47 tor1 kernel: [125982.993322] [<ffffffff81739344>] !__do_page_fault+0x184/0x560
May 14 11:02:47 tor1 kernel: [125982.993325] [<ffffffff810a3af5>] ? set_next_entity+0x95/0xb0
May 14 11:02:47 tor1 kernel: [125982.993328] [<ffffffff810135db>] ? !__switch_to+0x16b/0x4f0
May 14 11:02:47 tor1 kernel: [125982.993329] [<ffffffff8173973a>] do_page_fault+0x1a/0x70
May 14 11:02:47 tor1 kernel: [125982.993331] [<ffffffff81735a68>] page_fault+0x28/0x30
May 14 11:02:47 tor1 kernel: [125982.993350] Mem-Info:
May 14 11:02:47 tor1 kernel: [125982.993351] Node 0 DMA per-cpu:
May 14 11:02:47 tor1 kernel: [125982.993352] CPU 0: hi: 0, btch: 1 usd: 0
May 14 11:02:47 tor1 kernel: [125982.993353] CPU 1: hi: 0, btch: 1 usd: 0
May 14 11:02:47 tor1 kernel: [125982.993353] CPU 2: hi: 0, btch: 1 usd: 0
May 14 11:02:47 tor1 kernel: [125982.993354] CPU 3: hi: 0, btch: 1 usd: 0
May 14 11:02:47 tor1 kernel: [125982.993355] Node 0 DMA32 per-cpu:
May 14 11:02:47 tor1 kernel: [125982.993356] CPU 0: hi: 186, btch: 31 usd: 25
May 14 11:02:47 tor1 kernel: [125982.993356] CPU 1: hi: 186, btch: 31 usd: 2
May 14 11:02:47 tor1 kernel: [125982.993357] CPU 2: hi: 186, btch: 31 usd: 0
May 14 11:02:47 tor1 kernel: [125982.993358] CPU 3: hi: 186, btch: 31 usd: 26
May 14 11:02:47 tor1 kernel: [125982.993358] Node 0 Normal per-cpu:
May 14 11:02:47 tor1 kernel: [125982.993359] CPU 0: hi: 186, btch: 31 usd: 0
May 14 11:02:47 tor1 kernel: [125982.993360] CPU 1: hi: 186, btch: 31 usd: 0
May 14 11:02:47 tor1 kernel: [125982.993360] CPU 2: hi: 186, btch: 31 usd: 0
May 14 11:02:47 tor1 kernel: [125982.993361] CPU 3: hi: 186, btch: 31 usd: 0
May 14 11:02:47 tor1 kernel: [125982.993363] active_!anon:0 inactive_!anon:0 isolated_!anon:0
May 14 11:02:47 tor1 kernel: [125982.993363] active_!file:141 inactive_!file:204 isolated_!file:0
May 14 11:02:47 tor1 kernel: [125982.993363] !unevictable:0 !dirty:0 !writeback:0 !unstable:0
May 14 11:02:47 tor1 kernel: [125982.993363] !free:20517 slab_!reclaimable:7176 slab_!unreclaimable:41948
May 14 11:02:47 tor1 kernel: [125982.993363] !mapped:80 !shmem:0 !pagetables:692 !bounce:0
May 14 11:02:47 tor1 kernel: [125982.993363] free_!cma:0
May 14 11:02:47 tor1 kernel: [125982.993365] Node 0 DMA !free:15344kB !min:268kB !low:332kB !high:400kB active_!anon:0kB inactive_!anon:0kB active_!file:4kB inactive_!file:28kB !unevictable:0kB isolated(anon):0kB isolated(file):0kB !present:15976kB !managed:15892kB !mlocked:0kB !dirty:0kB !writeback:8kB !mapped:36kB !shmem:0kB slab_!reclaimable:0kB slab_!unreclaimable:156kB kernel_!stack:0kB !pagetables:4kB !unstable:0kB !bounce:0kB free_!cma:0kB writeback_!tmp:0kB pages_!scanned:18 all_unreclaimable? no
May 14 11:02:47 tor1 kernel: [125982.993368] lowmem_reserve[]: 0 2688 3771 3771
May 14 11:02:47 tor1 kernel: [125982.993370] Node 0 DMA32 !free:51080kB !min:46532kB !low:58164kB !high:69796kB active_!anon:0kB inactive_!anon:0kB active_!file:516kB inactive_!file:788kB !unevictable:0kB isolated(anon):0kB isolated(file):0kB !present:2832272kB !managed:2753204kB !mlocked:0kB !dirty:0kB !writeback:0kB !mapped:284kB !shmem:0kB slab_!reclaimable:15612kB slab_!unreclaimable:83432kB kernel_!stack:312kB !pagetables:2064kB !unstable:0kB !bounce:0kB free_!cma:0kB writeback_!tmp:0kB pages_!scanned:17 all_unreclaimable? no
May 14 11:02:47 tor1 kernel: [125982.993372] lowmem_reserve[]: 0 0 1082 1082
May 14 11:02:47 tor1 kernel: [125982.993373] Node 0 Normal !free:15644kB !min:18732kB !low:23412kB !high:28096kB active_!anon:0kB inactive_!anon:0kB active_!file:44kB inactive_!file:0kB !unevictable:0kB isolated(anon):0kB isolated(file):0kB !present:1179644kB !managed:1108484kB !mlocked:0kB !dirty:0kB !writeback:0kB !mapped:0kB !shmem:0kB slab_!reclaimable:13092kB slab_!unreclaimable:84204kB kernel_!stack:2072kB !pagetables:700kB !unstable:0kB !bounce:0kB free_!cma:0kB writeback_!tmp:0kB pages_!scanned:203 all_unreclaimable? yes
May 14 11:02:47 tor1 kernel: [125982.993376] lowmem_reserve[]: 0 0 0 0
May 14 11:02:47 tor1 kernel: [125982.993377] Node 0 DMA: 3*4kB (M) 3*8kB (UM) 2*16kB (UM) 0*32kB 1*64kB (U) 1*128kB (M) 1*256kB (M) 1*512kB (M) 2*1024kB (UM) 2*2048kB (MR) 2*4096kB (M) = 15364kB
May 14 11:02:47 tor1 kernel: [125982.993384] Node 0 DMA32: 303*4kB (UE) 662*8kB (UEM) 418*16kB (UEM) 952*32kB (UEM) 51*64kB (UM) 1*128kB (M) 0*256kB 0*512kB 0*1024kB 0*2048kB 1*4096kB (R) = 51148kB
May 14 11:02:47 tor1 kernel: [125982.993394] Node 0 Normal: 375*4kB (UEM) 330*8kB (UEM) 649*16kB (UEM) 3*32kB (M) 2*64kB (R) 1*128kB (R) 1*256kB (R) 1*512kB (R) 0*1024kB 0*2048kB 0*4096kB = 15644kB
May 14 11:02:47 tor1 kernel: [125982.993401] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
May 14 11:02:47 tor1 kernel: [125982.993401] 385 total pagecache pages
May 14 11:02:47 tor1 kernel: [125982.993402] 20 pages in swap cache
May 14 11:02:47 tor1 kernel: [125982.993403] Swap cache stats: add 2432647, delete 2432627, find 700250/1142133
May 14 11:02:47 tor1 kernel: [125982.993404] Free swap = 3627940kB
May 14 11:02:47 tor1 kernel: [125982.993404] Total swap = 4026364kB
May 14 11:02:47 tor1 kernel: [125982.993405] 1006973 pages RAM
May 14 11:02:47 tor1 kernel: [125982.993405] 0 pages HighMem/MovableOnly
May 14 11:02:47 tor1 kernel: [125982.993406] 17790 pages reserved
May 14 11:02:47 tor1 kernel: [125982.993406] [ pid ] uid tgid total_vm rss nr_ptes swapents oom_score_adj name
May 14 11:02:47 tor1 kernel: [125982.993422] ![32898] 0 32898 5073 0 13 251 0 upstart-udev-br
May 14 11:02:47 tor1 kernel: [125982.993423] ![32903] 0 32903 12900 1 27 228 -1000 systemd-udevd
May 14 11:02:47 tor1 kernel: [125982.993425] ![33049] 0 33049 3821 0 11 48 0 upstart-file-br
May 14 11:02:47 tor1 kernel: [125982.993426] ![33092] 102 33092 9813 1 23 95 0 dbus-daemon
May 14 11:02:47 tor1 kernel: [125982.993436] ![33096] 101 33096 63962 0 28 722 0 rsyslogd
May 14 11:02:47 tor1 kernel: [125982.993437] ![33119] 0 33119 10864 1 26 88 0 systemd-logind
May 14 11:02:47 tor1 kernel: [125982.993439] ![33206] 0 33206 3817 0 12 55 0 upstart-socket-
May 14 11:02:47 tor1 kernel: [125982.993440] ![33053] 0 33053 3699 1 12 41 0 getty
May 14 11:02:47 tor1 kernel: [125982.993441] ![33056] 0 33056 3699 1 12 41 0 getty
May 14 11:02:47 tor1 kernel: [125982.993442] ![33061] 0 33061 3699 1 12 39 0 getty
May 14 11:02:47 tor1 kernel: [125982.993443] ![33062] 0 33062 3699 1 11 40 0 getty
May 14 11:02:47 tor1 kernel: [125982.993444] ![33064] 0 33064 3699 1 12 39 0 getty
May 14 11:02:47 tor1 kernel: [125982.993446] ![33079] 0 33079 1094 0 8 35 0 acpid
May 14 11:02:47 tor1 kernel: [125982.993447] ![33089] 0 33089 15347 1 33 171 -1000 sshd
May 14 11:02:47 tor1 kernel: [125982.993448] ![33094] 0 33094 5915 0 17 81 0 cron
May 14 11:02:47 tor1 kernel: [125982.993449] ![33095] 0 33095 4786 0 12 48 0 atd
May 14 11:02:47 tor1 kernel: [125982.993450] ![33155] 0 33155 4801 34 13 73 0 irqbalance
May 14 11:02:47 tor1 kernel: [125982.993457] ![33180] 106 33180 111003 0 152 50520 0 tor
May 14 11:02:47 tor1 kernel: [125982.993458] ![33317] 108 33317 20352 0 41 9936 0 unbound
May 14 11:02:47 tor1 kernel: [125982.993459] ![33369] 105 33369 1871 12 9 33 0 vnstatd
May 14 11:02:47 tor1 kernel: [125982.993460] ![32890] 0 32890 3699 1 11 40 0 getty
May 14 11:02:47 tor1 kernel: [125982.993461] ![32991] 1002 32991 2867 0 10 84 0 memlog.sh
May 14 11:02:47 tor1 kernel: [125982.993462] ![33057] 106 33057 97196 0 128 36538 0 tor
May 14 11:02:47 tor1 kernel: [125982.993464] ![57323] 1002 57323 2867 0 10 91 0 memlog.sh
May 14 11:02:47 tor1 kernel: [125982.993465] ![57325] 1002 57325 2218 78 10 32 0 grep
May 14 11:02:47 tor1 kernel: [125982.993466] ![57326] 1002 57326 2746 44 11 46 0 sed
May 14 11:02:47 tor1 kernel: [125982.993467] Out of memory: Kill process 33180 (tor) score 25 or sacrifice child
May 14 11:02:47 tor1 kernel: [125982.993478] Killed process 33180 (tor) !total-vm:444012kB, !anon-rss:0kB, !file-rss:0kB
```
notices.log does not show anything around the kill time. First record ist the restart of the process at 20:32
```
May 14 06:54:03.000 [notice] Tor 0.3.0.5-rc (git-61f68662421142d2) opening new log file.
May 14 07:13:01.000 [warn] eventdns: All nameservers have failed
May 14 07:13:01.000 [notice] eventdns: Nameserver 127.0.0.1:53 is back up
May 14 07:47:36.000 [warn] eventdns: All nameservers have failed
May 14 07:47:36.000 [notice] eventdns: Nameserver 127.0.0.1:53 is back up
May 14 08:10:38.000 [warn] eventdns: All nameservers have failed
May 14 08:10:38.000 [notice] eventdns: Nameserver 127.0.0.1:53 is back up
May 14 08:12:28.000 [warn] eventdns: All nameservers have failed
May 14 08:12:28.000 [notice] eventdns: Nameserver 127.0.0.1:53 is back up
May 14 08:20:08.000 [warn] eventdns: All nameservers have failed
May 14 08:20:09.000 [notice] eventdns: Nameserver 127.0.0.1:53 is back up
May 14 20:23:18.000 [notice] Tor 0.3.0.5-rc (git-61f68662421142d2) opening log file.
May 14 20:23:18.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.
May 14 20:23:18.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
May 14 20:23:18.000 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now.
```
We are operation the * [Exit Servers](https://atlas.torproject.org/#search/digiges) since years and they became unstable about a week ago. No changes other the normal software updates where performed.
Other than the two tor processes an local unbound resolver and ssh are running.
It feels like an memory leak. Since tor is the one getting killed I assume the problem would be the tor software. Any thoughts ?
**Trac**:
**Username**: DeSTor: 0.3.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/22252get_options_mutable: Assertion global_options failed; SIGABRT2020-06-13T15:08:54ZTracget_options_mutable: Assertion global_options failed; SIGABRTVersion:
Tor 0.3.1.0-alpha-dev (git-44102714460aafe5)
Input file hexdump:
```
00000000 4c 00 20 20 66 6f 6f 2e 6c 6f 67 0a 0a |L. foo.log..|
0000000d
```
How to reproduce:
```
$ ./src/or/tor -f <attached input file> --ver...Version:
Tor 0.3.1.0-alpha-dev (git-44102714460aafe5)
Input file hexdump:
```
00000000 4c 00 20 20 66 6f 6f 2e 6c 6f 67 0a 0a |L. foo.log..|
0000000d
```
How to reproduce:
```
$ ./src/or/tor -f <attached input file> --verify-config
```
gdb:
```
Program terminated with signal SIGABRT, Aborted.
#0 0x00007fb6f1d31a10 in raise () from /usr/lib/libc.so.6
(gdb) bt
#0 0x00007fb6f1d31a10 in raise () from /usr/lib/libc.so.6
#1 0x00007fb6f1d3313a in abort () from /usr/lib/libc.so.6
#2 0x000055a0ed6e39a3 in get_options_mutable () at src/or/config.c:768
#3 get_options () at src/or/config.c:776
#4 0x000055a0ed5b224f in networkstatus_get_latest_consensus () at src/or/networkstatus.c:1370
#5 networkstatus_get_param (ns=0x2, param_name=0x55a0ed8e2190 "cbtdisabled", default_val=0, min_val=0,
max_val=1) at src/or/networkstatus.c:2368
#6 0x000055a0ed6d0f4b in circuit_build_times_disabled (options=0x55a0eeef0c50)
at src/or/circuitstats.c:113
#7 0x000055a0ed6ef697 in options_validate (old_options=<optimized out>, options=<optimized out>,
default_options=<optimized out>, from_setconf=<optimized out>, msg=<optimized out>)
at src/or/config.c:3493
#8 0x000055a0ed6faa72 in options_init_from_string (cf_defaults=<optimized out>, cf=<optimized out>,
command=<optimized out>, command_arg=<optimized out>, msg=<optimized out>) at src/or/config.c:5170
#9 0x000055a0ed6f8eba in options_init_from_torrc (argc=<optimized out>, argv=<optimized out>)
at src/or/config.c:4968
#10 0x000055a0ed59a184 in tor_init (argc=<optimized out>, argv=<optimized out>) at src/or/main.c:3080
#11 0x000055a0ed59aeb8 in tor_main (argc=2, argv=0x7ffe29220520) at src/or/main.c:3707
#12 0x000055a0ed5923e9 in main (argc=2, argv=0x7ffe29220520) at src/or/tor_main.c:34
```
valgrind:
```
==32291== Memcheck, a memory error detector
==32291== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==32291== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
==32291== Command: ./src/or/tor -f /tmp/crash --verify-config
==32291==
May 14 10:44:50.978 [notice] Tor 0.3.1.0-alpha-dev (git-44102714460aafe5) running on Linux with Libevent 2.0.22-stable, OpenSSL 1.1.0e, Zlib 1.2.11, Liblzma 5.2.3, and Libzstd N/A.
May 14 10:44:51.044 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
May 14 10:44:51.046 [notice] This version is not a stable Tor release. Expect more bugs than usual.
May 14 10:44:51.079 [notice] Read configuration file "/tmp/crash".
May 14 10:44:51.445 [warn] The abbreviation 'L' is deprecated. Please use 'LearnCircuitBuildTimeout' instead
May 14 10:44:51.550 [err] tor_assertion_failed_: Bug: src/or/config.c:768: get_options_mutable: Assertion global_options failed; aborting. (on Tor 0.3.1.0-alpha-dev 44102714460aafe5)
May 14 10:44:51.560 [err] Bug: Assertion global_options failed in get_options_mutable at src/or/config.c:768. Stack trace: (on Tor 0.3.1.0-alpha-dev 44102714460aafe5)
May 14 10:44:51.561 [err] Bug: ./src/or/tor(log_backtrace+0x66) [0x3b3d86] (on Tor 0.3.1.0-alpha-dev 44102714460aafe5)
May 14 10:44:51.561 [err] Bug: ./src/or/tor(tor_assertion_failed_+0xc3) [0x3ea183] (on Tor 0.3.1.0-alpha-dev 44102714460aafe5)
May 14 10:44:51.562 [err] Bug: ./src/or/tor(get_options+0x9e) [0x2a299e] (on Tor 0.3.1.0-alpha-dev 44102714460aafe5)
May 14 10:44:51.562 [err] Bug: ./src/or/tor(networkstatus_get_param+0x6f) [0x17124f] (on Tor 0.3.1.0-alpha-dev 44102714460aafe5)
May 14 10:44:51.562 [err] Bug: ./src/or/tor(circuit_build_times_disabled+0x5b) [0x28ff4b] (on Tor 0.3.1.0-alpha-dev 44102714460aafe5)
May 14 10:44:51.562 [err] Bug: ./src/or/tor(+0x1a6697) [0x2ae697] (on Tor 0.3.1.0-alpha-dev 44102714460aafe5)
May 14 10:44:51.562 [err] Bug: ./src/or/tor(options_init_from_string+0x862) [0x2b9a72] (on Tor 0.3.1.0-alpha-dev 44102714460aafe5)
May 14 10:44:51.562 [err] Bug: ./src/or/tor(options_init_from_torrc+0x6aa) [0x2b7eba] (on Tor 0.3.1.0-alpha-dev 44102714460aafe5)
May 14 10:44:51.562 [err] Bug: ./src/or/tor(tor_init+0x7e4) [0x159184] (on Tor 0.3.1.0-alpha-dev 44102714460aafe5)
May 14 10:44:51.562 [err] Bug: ./src/or/tor(tor_main+0x88) [0x159eb8] (on Tor 0.3.1.0-alpha-dev 44102714460aafe5)
May 14 10:44:51.565 [err] Bug: ./src/or/tor(main+0x39) [0x1513e9] (on Tor 0.3.1.0-alpha-dev 44102714460aafe5)
May 14 10:44:51.565 [err] Bug: /usr/lib/libc.so.6(__libc_start_main+0xf1) [0x673e511] (on Tor 0.3.1.0-alpha-dev 44102714460aafe5)
May 14 10:44:51.565 [err] Bug: ./src/or/tor(_start+0x2a) [0x1512aa] (on Tor 0.3.1.0-alpha-dev 44102714460aafe5)
==32291==
==32291== Process terminating with default action of signal 6 (SIGABRT): dumping core
==32291== at 0x6751A10: raise (in /usr/lib/libc-2.25.so)
==32291== by 0x6753139: abort (in /usr/lib/libc-2.25.so)
==32291== by 0x2A29A2: get_options_mutable (config.c:768)
==32291== by 0x2A29A2: get_options (config.c:776)
==32291== by 0x17124E: networkstatus_get_latest_consensus (networkstatus.c:1370)
==32291== by 0x17124E: networkstatus_get_param (networkstatus.c:2368)
==32291== by 0x28FF4A: circuit_build_times_disabled (circuitstats.c:113)
==32291== by 0x2AE696: options_validate (config.c:3493)
==32291== by 0x2B9A71: options_init_from_string (config.c:5170)
==32291== by 0x2B7EB9: options_init_from_torrc (config.c:4968)
==32291== by 0x159183: tor_init (main.c:3080)
==32291== by 0x159EB7: tor_main (main.c:3707)
==32291== by 0x1513E8: main (tor_main.c:34)
==32291==
==32291== HEAP SUMMARY:
==32291== in use at exit: 91,573 bytes in 3,013 blocks
==32291== total heap usage: 5,285 allocs, 2,272 frees, 187,424 bytes allocated
==32291==
==32291== LEAK SUMMARY:
==32291== definitely lost: 0 bytes in 0 blocks
==32291== indirectly lost: 0 bytes in 0 blocks
==32291== possibly lost: 0 bytes in 0 blocks
==32291== still reachable: 91,573 bytes in 3,013 blocks
==32291== suppressed: 0 bytes in 0 blocks
==32291== Rerun with --leak-check=full to see details of leaked memory
==32291==
==32291== For counts of detected and suppressed errors, rerun with: -v
==32291== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
[1] 32291 abort valgrind ./src/or/tor -f /tmp/crash --verify-config
```
Best Regards,
Stephan Zeisberg
**Trac**:
**Username**: stzeTor: 0.3.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/22246ASSERT failure on v0.3.0.62020-06-13T15:08:52ZTracASSERT failure on v0.3.0.6```
May 10 12:57:20.000 [err] tor_assertion_failed_(): Bug: src/common/container.c:1430: digest256map_get: Assertion map failed; aborting. (on Tor 0.3.0.6 47d2e4f06ec26a79)
May 10 12:57:20.000 [err] Bug: Assertion map failed in digest256...```
May 10 12:57:20.000 [err] tor_assertion_failed_(): Bug: src/common/container.c:1430: digest256map_get: Assertion map failed; aborting. (on Tor 0.3.0.6 47d2e4f06ec26a79)
May 10 12:57:20.000 [err] Bug: Assertion map failed in digest256map_get at src/common/container.c:1430. Stack trace: (on Tor 0.3.0.6 47d2e4f06ec26a79)
May 10 12:57:20.000 [err] Bug: /usr/bin/tor(log_backtrace+0x42) [0x7f2bfbdefc12] (on Tor 0.3.0.6 47d2e4f06ec26a79)
May 10 12:57:20.000 [err] Bug: /usr/bin/tor(tor_assertion_failed_+0xa3) [0x7f2bfbe07b53] (on Tor 0.3.0.6 47d2e4f06ec26a79)
May 10 12:57:20.000 [err] Bug: /usr/bin/tor(digest256map_get+0x11b) [0x7f2bfbdf8d8b] (on Tor 0.3.0.6 47d2e4f06ec26a79)
May 10 12:57:20.000 [err] Bug: /usr/bin/tor(hs_cache_lookup_as_dir+0x74) [0x7f2bfbde3714] (on Tor 0.3.0.6 47d2e4f06ec26a79)
May 10 12:57:20.000 [err] Bug: /usr/bin/tor(+0x192323) [0x7f2bfbdb3323] (on Tor 0.3.0.6 47d2e4f06ec26a79)
May 10 12:57:20.000 [err] Bug: /usr/bin/tor(connection_dir_process_inbuf+0x6a2) [0x7f2bfbdb7e42] (on Tor 0.3.0.6 47d2e4f06ec26a79)
May 10 12:57:20.000 [err] Bug: /usr/bin/tor(connection_handle_read+0x794) [0x7f2bfbd92af4] (on Tor 0.3.0.6 47d2e4f06ec26a79)
May 10 12:57:20.000 [err] Bug: /usr/bin/tor(+0xbc8a1) [0x7f2bfbcdd8a1] (on Tor 0.3.0.6 47d2e4f06ec26a79)
May 10 12:57:20.000 [err] Bug: /usr/bin/tor(event_base_loop+0x804) [0x7f2bfbe692b4] (on Tor 0.3.0.6 47d2e4f06ec26a79)
May 10 12:57:20.000 [err] Bug: /usr/bin/tor(do_main_loop+0x3f3) [0x7f2bfbcd91e3] (on Tor 0.3.0.6 47d2e4f06ec26a79)
May 10 12:57:20.000 [err] Bug: /usr/bin/tor(tor_main+0xe75) [0x7f2bfbcda305] (on Tor 0.3.0.6 47d2e4f06ec26a79)
May 10 12:57:20.000 [err] Bug: /usr/bin/tor(main+0x19) [0x7f2bfbcd6319] (on Tor 0.3.0.6 47d2e4f06ec26a79)
May 10 12:57:20.000 [err] Bug: /lib64/libc.so.6(__libc_start_main+0xfd) [0x7f2bfadf4d1d] (on Tor 0.3.0.6 47d2e4f06ec26a79)
May 10 12:57:20.000 [err] Bug: /usr/bin/tor(+0xb5229) [0x7f2bfbcd6229] (on Tor 0.3.0.6 47d2e4f06ec26a79)
```
**Trac**:
**Username**: tmpname0901Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/21953Dealing with Tor hardening on Windows properly2020-06-13T15:07:49ZcypherpunksDealing with Tor hardening on Windows properlyWhile gk is waiting (for something?) in #12426, Tor needs its security mitigations to be corrected according to https://blogs.microsoft.com/microsoftsecure/2009/08/06/setting-sdl-memory-related-requirements-before-your-application-starts...While gk is waiting (for something?) in #12426, Tor needs its security mitigations to be corrected according to https://blogs.microsoft.com/microsoftsecure/2009/08/06/setting-sdl-memory-related-requirements-before-your-application-starts/ before the release.
So, adding
```
HeapSetInformation(NULL, HeapEnableTerminationOnCorruption, NULL, 0);
```
after https://gitweb.torproject.org/tor.git/tree/src/or/main.c?h=release-0.3.0#n3570
and changing
```
if (setdeppolicy) setdeppolicy(1); /* PROCESS_DEP_ENABLE */
```
with
```
if (setdeppolicy) setdeppolicy(3); /* PROCESS_DEP_ENABLE | PROCESS_DEP_DISABLE_ATL_THUNK_EMULATION */
```
will do the trick.Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/21894Base32_encode: *actually* allow inputs of odd sizes2020-06-13T15:07:41ZNick MathewsonBase32_encode: *actually* allow inputs of odd sizesWhen we "fixed" #18280 in 4e4a7d2b0c199227252a742541461ec4cc35d358 in 0291 it appears that we introduced a bug: The base32_encode function can read off the end of the input buffer, if the input buffer size modulo 5 is not equal to 0 or 3...When we "fixed" #18280 in 4e4a7d2b0c199227252a742541461ec4cc35d358 in 0291 it appears that we introduced a bug: The base32_encode function can read off the end of the input buffer, if the input buffer size modulo 5 is not equal to 0 or 3.
This is not _completely_ horrible, for two reasons:
* The extra bits that are read are never actually used: so this is only a crash when asan is enabled, in the worst case.
* The input sizes passed to base32_encode are only ever multiples of 5. They are all either DIGEST_LEN (20), REND_SERVICE_ID_LEN (10), sizeof(rand_bytes) in addressmap.c (10), or an input in crypto.c that is forced to a multiple of 5. So this bug can't actually trigger.
Nonetheless, let's fix it!Tor: 0.3.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/21826clang warnings because of "empty" hs_service.c file in 0.3.02020-06-13T15:07:31ZGeorge Kadianakisclang warnings because of "empty" hs_service.c file in 0.3.0Currently (in 0.3.0) the code in `hs_service.c` is disabled using `#ifdef TOR_UNIT_TESTS` and is only used for unittests. We will remove these `#ifdef` guards in 0.3.2 when we merge the rest of the service-side code.
Unfortunately, as i...Currently (in 0.3.0) the code in `hs_service.c` is disabled using `#ifdef TOR_UNIT_TESTS` and is only used for unittests. We will remove these `#ifdef` guards in 0.3.2 when we merge the rest of the service-side code.
Unfortunately, as it seems having an empty .c file is no good, since empty translation units (i.e. files) are undefined behavior in C.
Sebastian pointed this out, and said that his clang is throwing warnings at him because of that. He says that compilation proceeds normally, but it might be a good thing to fix anyhow.
We could fix this by adding a static variable on top to silence the warning, or by removing the #ifdef guards.Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/21825no symbol warning for hs_service.c2020-06-13T15:07:31ZSebastian Hahnno symbol warning for hs_service.cDuring compilation, this warning is thrown:
ranlib: file: src/or/libtor.a(hs_service.o) has no symbols
Probably because there is no content other than unit tests.
(Also see the duplicate #21826 for more info)During compilation, this warning is thrown:
ranlib: file: src/or/libtor.a(hs_service.o) has no symbols
Probably because there is no content other than unit tests.
(Also see the duplicate #21826 for more info)Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/21799Unittest fail: FAIL ../tor/src/test/test_entrynodes.c:618: assert(smartlist_l...2020-06-13T15:07:25ZGeorge KadianakisUnittest fail: FAIL ../tor/src/test/test_entrynodes.c:618: assert(smartlist_len(gs_br->sampled_entry_guards) OP_EQ 2): 1 vs 2```
entrynodes/parse_from_state_full: [forking]
FAIL ../tor/src/test/test_entrynodes.c:618: assert(smartlist_len(gs_br->sampled_entry_guards) OP_EQ 2): 1 vs 2
[parse_from_state_full FAILED]
```
The entry nodes unittests are failing...```
entrynodes/parse_from_state_full: [forking]
FAIL ../tor/src/test/test_entrynodes.c:618: assert(smartlist_len(gs_br->sampled_entry_guards) OP_EQ 2): 1 vs 2
[parse_from_state_full FAILED]
```
The entry nodes unittests are failing because of an expired timestmap. Specifically:
```
"Guard in=bridges rsa_id=5800000000000000000000000000000000000000 "
"bridge_addr=37.218.246.143:28366 "
"sampled_on=2016-11-18T15:07:34 sampled_by=0.3.0.0-alpha-dev listed=1\n";
```
since it was sampled over 120 days ago we get:
```
Mar 22 11:44:29.227 [info] sampled_guards_update_from_consensus(): Removing sampled guard $5800000000000000000000000000000000000000 ($5800000000000000000000000000000000000000): it was sampled over 120 days ago, but never
confirmed.
```
The fix is to use `get_yesterday_date_str()` instead of a hardcoded date. It's not trivial tho because in the end the test tries to be smart and predict how the state is gonna be modified, so we need to also work on the `tt_str_op(joined, OP_EQ, ...)` part.
Also, there seem to be more unittests with hardcoded 2016 dates. We should see if those are ticking bombs as well.Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/21720Update Directory Server Options section for automatic DirCache2020-06-13T15:07:17ZteorUpdate Directory Server Options section for automatic DirCacheThis section header is wrong:
```
DIRECTORY SERVER OPTIONS
The following options are useful only for directory servers (that is,
if DirPort is non-zero):
```
It should read:
```
DIRECTORY SERVER OPTIONS
The followin...This section header is wrong:
```
DIRECTORY SERVER OPTIONS
The following options are useful only for directory servers (that is,
if DirPort is non-zero):
```
It should read:
```
DIRECTORY SERVER OPTIONS
The following options are useful only for directory servers:
(Relays with enough bandwidth automatically become directory
servers, see DirCache for details.)
```Tor: 0.3.0.x-final