Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:50:12Zhttps://gitlab.torproject.org/legacy/trac/-/issues/33039Memory leaks in handle_control_getconf2020-06-13T15:50:12ZNick MathewsonMemory leaks in handle_control_getconfFound while investigating #33006:
```
=================================================================
==180005==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 32 byte(s) in 1 object(s) allocated from:
#0 0x7fb54c5cdc5...Found while investigating #33006:
```
=================================================================
==180005==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 32 byte(s) in 1 object(s) allocated from:
#0 0x7fb54c5cdc58 in __interceptor_malloc (/lib64/libasan.so.5+0x10dc58)
#1 0x55a4af274f3a in tor_malloc_ src/lib/malloc/malloc.c:45
#2 0x55a4af274fd0 in tor_malloc_zero_ src/lib/malloc/malloc.c:71
#3 0x55a4af2371ca in config_line_append src/lib/encoding/confline.c:40
#4 0x55a4aeffaec7 in control_reply_add_one_kv src/feature/control/control_proto.c:345
#5 0x55a4aefdd2ae in handle_control_getconf src/feature/control/control_cmd.c:307
#6 0x55a4aefe54b2 in handle_single_control_command src/feature/control/control_cmd.c:2376
#7 0x55a4aefe54b2 in handle_control_command src/feature/control/control_cmd.c:2407
#8 0x55a4aefd6e01 in connection_control_process_inbuf src/feature/control/control.c:508
#9 0x55a4aeee0e01 in connection_handle_read_impl src/core/mainloop/connection.c:3737
#10 0x55a4aeee0e01 in connection_handle_read src/core/mainloop/connection.c:3777
#11 0x55a4aeeecf00 in conn_read_callback src/core/mainloop/mainloop.c:892
#12 0x7fb54c32abb6 (/lib64/libevent-2.1.so.6+0x25bb6)
Indirect leak of 26 byte(s) in 1 object(s) allocated from:
#0 0x7fb54c55652d in strdup (/lib64/libasan.so.5+0x9652d)
#1 0x55a4af2751d0 in tor_strdup_ src/lib/malloc/malloc.c:165
#2 0x55a4af2371d5 in config_line_append src/lib/encoding/confline.c:41
#3 0x55a4aeffaec7 in control_reply_add_one_kv src/feature/control/control_proto.c:345
#4 0x55a4aefdd2ae in handle_control_getconf src/feature/control/control_cmd.c:307
#5 0x55a4aefe54b2 in handle_single_control_command src/feature/control/control_cmd.c:2376
#6 0x55a4aefe54b2 in handle_control_command src/feature/control/control_cmd.c:2407
#7 0x55a4aefd6e01 in connection_control_process_inbuf src/feature/control/control.c:508
#8 0x55a4aeee0e01 in connection_handle_read_impl src/core/mainloop/connection.c:3737
#9 0x55a4aeee0e01 in connection_handle_read src/core/mainloop/connection.c:3777
#10 0x55a4aeeecf00 in conn_read_callback src/core/mainloop/mainloop.c:892
#11 0x7fb54c32abb6 (/lib64/libevent-2.1.so.6+0x25bb6)
Indirect leak of 7 byte(s) in 1 object(s) allocated from:
#0 0x7fb54c55652d in strdup (/lib64/libasan.so.5+0x9652d)
#1 0x55a4af2751d0 in tor_strdup_ src/lib/malloc/malloc.c:165
#2 0x55a4af2371f5 in config_line_append src/lib/encoding/confline.c:42
#3 0x55a4aeffaec7 in control_reply_add_one_kv src/feature/control/control_proto.c:345
#4 0x55a4aefdd2ae in handle_control_getconf src/feature/control/control_cmd.c:307
#5 0x55a4aefe54b2 in handle_single_control_command src/feature/control/control_cmd.c:2376
#6 0x55a4aefe54b2 in handle_control_command src/feature/control/control_cmd.c:2407
#7 0x55a4aefd6e01 in connection_control_process_inbuf src/feature/control/control.c:508
#8 0x55a4aeee0e01 in connection_handle_read_impl src/core/mainloop/connection.c:3737
#9 0x55a4aeee0e01 in connection_handle_read src/core/mainloop/connection.c:3777
#10 0x55a4aeeecf00 in conn_read_callback src/core/mainloop/mainloop.c:892
#11 0x7fb54c32abb6 (/lib64/libevent-2.1.so.6+0x25bb6)
SUMMARY: AddressSanitizer: 65 byte(s) leaked in 3 allocation(s).
Exit code was 1
success (15.21s)
```Tor: 0.4.3.x-finalTaylor YuTaylor Yuhttps://gitlab.torproject.org/legacy/trac/-/issues/29599Test failure due to missing sr_state_free[_all]() in shared-random unit tests2020-06-13T15:38:38ZteorTest failure due to missing sr_state_free[_all]() in shared-random unit testsIt looks like Travis recently upgraded to a clang with a (better) LeakSanitizer.
The following tests have memory leaks:
* shared-random/vote
* shared-random/sr_compute_srv
* shared-random/state_transition
They are missing a call to sr_...It looks like Travis recently upgraded to a clang with a (better) LeakSanitizer.
The following tests have memory leaks:
* shared-random/vote
* shared-random/sr_compute_srv
* shared-random/state_transition
They are missing a call to sr_state_free() in 0.2.9 and later.
But it's spelt sr_state_free_all() in 0.3.3 and later.Tor: 0.2.9.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/29552memory leak: protover_contains_long_protocol_names in protover.c calls parse_...2020-06-13T15:38:28ZTracmemory leak: protover_contains_long_protocol_names in protover.c calls parse_protocol_list, but doesn't free smartlist returned (treats it as a boolean)The function parse_protocol_list in protover.c allocates a smartlist, and returns a pointer to the smartlist as long as there are no parse errors. The funcction protover_contains_long_protocol_names calls the former, but should capture ...The function parse_protocol_list in protover.c allocates a smartlist, and returns a pointer to the smartlist as long as there are no parse errors. The funcction protover_contains_long_protocol_names calls the former, but should capture and delete the returned smartlist if it is not null.
I searched the database for these function names and they didn't show up, so I assume this is unreported and still a problem. I apologize if I missed it somehow.
**Trac**:
**Username**: drjohnson1984https://gitlab.torproject.org/legacy/trac/-/issues/28257CID 1440805: Memory leak in configured_nameserver_address() due to #219002020-06-13T15:33:33ZteorCID 1440805: Memory leak in configured_nameserver_address() due to #21900```
** CID 1440805: Resource leaks (RESOURCE_LEAK)
/src/feature/relay/dns.c: 1389 in configured_nameserver_address()
________________________________________________________________________________________________________
*** CID 144...```
** CID 1440805: Resource leaks (RESOURCE_LEAK)
/src/feature/relay/dns.c: 1389 in configured_nameserver_address()
________________________________________________________________________________________________________
*** CID 1440805: Resource leaks (RESOURCE_LEAK)
/src/feature/relay/dns.c: 1389 in configured_nameserver_address()
1383 tor_addr_t *tor_addr = tor_malloc(sizeof(tor_addr_t));
1384 if (tor_addr_from_sockaddr(tor_addr,
1385 (const struct sockaddr *)&sa,
1386 NULL) == 0) {
1387 return tor_addr;
1388 }
CID 1440805: Resource leaks (RESOURCE_LEAK)
Variable "tor_addr" going out of scope leaks the storage it points to.
1389 }
1390
1391 return NULL;
1392 }
1393 #endif
```Tor: 0.4.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/24150Memory leak in v3 hsdesc parsing with empty encrypted data.2020-06-13T15:16:58ZNick MathewsonMemory leak in v3 hsdesc parsing with empty encrypted data.When we get a v3 hsdesc where the decrypted part starts with a NUL byte, then decrypt_desc_layer will return 0, since the length of the output is 0. But "0" can also mean that there's an error in the
decryption.
Found with OSS-fuzz.When we get a v3 hsdesc where the decrypted part starts with a NUL byte, then decrypt_desc_layer will return 0, since the length of the output is 0. But "0" can also mean that there's an error in the
decryption.
Found with OSS-fuzz.Tor: 0.3.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/23053Memory leak of unix_socket_path when validating multiple unix sockets2020-06-13T15:12:05ZNick MathewsonMemory leak of unix_socket_path when validating multiple unix socketsThis is CID 1415725This is CID 1415725Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/22803Memory leak in link-handshake/certs_ok_ed255192020-06-13T15:11:11ZNick MathewsonMemory leak in link-handshake/certs_ok_ed25519=================================================================
==24816==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 160 byte(s) in 1 object(s) allocated from:
#0 0x7fe721373e60 in malloc (/lib64/libasan.so.3+0xc6e6...=================================================================
==24816==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 160 byte(s) in 1 object(s) allocated from:
#0 0x7fe721373e60 in malloc (/lib64/libasan.so.3+0xc6e60)
#1 0x5582ccbf96ea in tor_malloc_ src/common/util.c:150
#2 0x5582ccbf9791 in tor_malloc_zero_ src/common/util.c:178
#3 0x5582ccb7d8ae in tor_x509_cert_new__real src/common/tortls.c:677
#4 0x5582cc61f504 in test_link_handshake_certs_ok src/test/test_link_handshake.c:232
#5 0x5582cc783a78 in testcase_run_bare_ src/ext/tinytest.c:106
#6 0x5582cc783f76 in testcase_run_forked_ src/ext/tinytest.c:190
#7 0x5582cc783f76 in testcase_run_one src/ext/tinytest.c:248
#8 0x5582cc785465 in tinytest_main src/ext/tinytest.c:435
#9 0x5582cc3d7846 in main src/test/testing_common.c:319
#10 0x7fe71e6c4400 in __libc_start_main (/lib64/libc.so.6+0x20400)
Indirect leak of 3050 byte(s) in 58 object(s) allocated from:
#0 0x7fe721373e60 in malloc (/lib64/libasan.so.3+0xc6e60)
#1 0x7fe7204e03e7 in CRYPTO_malloc (/lib64/libcrypto.so.10+0x6e3e7)
Indirect leak of 579 byte(s) in 1 object(s) allocated from:
#0 0x7fe721373e60 in malloc (/lib64/libasan.so.3+0xc6e60)
#1 0x5582ccbf96ea in tor_malloc_ src/common/util.c:150
#2 0x5582ccb7d904 in tor_x509_cert_new__real src/common/tortls.c:687
#3 0x5582cc61f504 in test_link_handshake_certs_ok src/test/test_link_handshake.c:232
#4 0x5582cc783a78 in testcase_run_bare_ src/ext/tinytest.c:106
#5 0x5582cc783f76 in testcase_run_forked_ src/ext/tinytest.c:190
#6 0x5582cc783f76 in testcase_run_one src/ext/tinytest.c:248
#7 0x5582cc785465 in tinytest_main src/ext/tinytest.c:435
#8 0x5582cc3d7846 in main src/test/testing_common.c:319
#9 0x7fe71e6c4400 in __libc_start_main (/lib64/libc.so.6+0x20400)Tor: 0.3.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/22370Stop leaking routerinfos that are rejected due to keypinning2020-06-13T15:09:24ZteorStop leaking routerinfos that are rejected due to keypinningWhen we added the keypinning code to dirserv_add_descriptor, we forgot to free rejected routerinfos.
We should backport this to 0.2.9, because it is the earliest version run by the public directory authorities. (And it's LTS.)When we added the keypinning code to dirserv_add_descriptor, we forgot to free rejected routerinfos.
We should backport this to 0.2.9, because it is the earliest version run by the public directory authorities. (And it's LTS.)Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/21682memory leak at shutdown2020-06-13T15:07:13Zcypherpunksmemory leak at shutdown=================================================================
==2636==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 7 byte(s) in 1 object(s) allocated from:
#0 0x5566c0999f40 in __interceptor_strdup (/home/reince/to...=================================================================
==2636==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 7 byte(s) in 1 object(s) allocated from:
#0 0x5566c0999f40 in __interceptor_strdup (/home/reince/tor-browser_en-US/Browser/TorBrowser/Tor/tor+0x4f0f40)
#1 0x5566c0ec9125 in tor_strdup_ /home/reince/tor/src/common/util.c:280:15
#2 0x5566c0cfe147 in config_get_assigned_option /home/reince/tor/src/or/confparse.c:690:17
#3 0x5566c0ccd659 in option_get_assignment /home/reince/tor/src/or/config.c:2299:10
#4 0x5566c0d77484 in handle_control_getconf /home/reince/tor/src/or/control.c:1033:31
#5 0x5566c0d77484 in connection_control_process_inbuf /home/reince/tor/src/or/control.c:5032
#6 0x5566c0d35eba in connection_process_inbuf /home/reince/tor/src/or/connection.c:4476:14
#7 0x5566c0d2596b in connection_handle_read_impl /home/reince/tor/src/or/connection.c:3451:7
#8 0x5566c0d2596b in connection_handle_read /home/reince/tor/src/or/connection.c:3492
#9 0x5566c0a44791 in conn_read_callback /home/reince/tor/src/or/main.c:733:7
#10 0x7f3842c871fc in event_persist_closure /home/reince/libevent/event.c:1580:9
#11 0x7f3842c871fc in event_process_active_single_queue /home/reince/libevent/event.c:1639
SUMMARY: AddressSanitizer: 7 byte(s) leaked in 1 allocation(s).
just once when shutting down
libevent c199df7bc78824ff579ff34c5f9f922034e8fa31
tor efa5bbaba07d20d1aacff7d1d2a5fe08a6ec2d72Tor: 0.3.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19466Memory leak while parsing a crafted torrc2020-06-13T14:58:50ZTracMemory leak while parsing a crafted torrcThere is a memory leak while tor parses a crafted config.
~ # tor --verify-config -f $CRAFTED_TORRC
Jun 20 15:59:36.509 [notice] Tor v0.2.7.6 running on Linux with Libevent 2.0.22-stable, OpenSSL 1.0.2h and Zlib 1.2.8.
Jun 20 15:59:36.5...There is a memory leak while tor parses a crafted config.
~ # tor --verify-config -f $CRAFTED_TORRC
Jun 20 15:59:36.509 [notice] Tor v0.2.7.6 running on Linux with Libevent 2.0.22-stable, OpenSSL 1.0.2h and Zlib 1.2.8.
Jun 20 15:59:36.531 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Jun 20 15:59:36.531 [notice] Read configuration file "/tmp/afl/out/AFL0/crashes/id:000041,sig:06,src:000000,op:havoc,rep:32".
Jun 20 15:59:36.553 [warn] The abbreviation 'no' is deprecated. Please use 'NodeFamily' instead
Jun 20 15:59:36.571 [warn] Entry 'kltorpc ' in NodeFamily is malformed. Discarding entire list.
Jun 20 15:59:36.572 [warn] Entry 'kltorpc ' in NodeFamily is malformed. Discarding entire list.
Jun 20 15:59:36.572 [err] Reading config failed--see warnings above.
=================================================================
==28441==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 16 byte(s) in 1 object(s) allocated from:
#0 0x4eb568 in malloc (/usr/bin/tor+0x4eb568)
#1 0x9fbc6b in tor_malloc_ /tmp/portage/net-misc/tor-0.2.7.6/work/tor-0.2.7.6/src/common/util.c:171:12
#2 0x9c7b82 in smartlist_new /tmp/portage/net-misc/tor-0.2.7.6/work/tor-0.2.7.6/src/common/container.c:34:21
#3 0x7e73fe in options_init_from_string /tmp/portage/net-misc/tor-0.2.7.6/work/tor-0.2.7.6/src/or/config.c:4720:7
#4 0x7e4f09 in options_init_from_torrc /tmp/portage/net-misc/tor-0.2.7.6/work/tor-0.2.7.6/src/or/config.c:4524:12
#5 0x52cf11 in tor_init /tmp/portage/net-misc/tor-0.2.7.6/work/tor-0.2.7.6/src/or/main.c:2709:7
#6 0x52e2a6 in tor_main /tmp/portage/net-misc/tor-0.2.7.6/work/tor-0.2.7.6/src/or/main.c:3271:7
#7 0x51c51d in main /tmp/portage/net-misc/tor-0.2.7.6/work/tor-0.2.7.6/src/or/tor_main.c:30:11
#8 0x444018 in _start (/usr/bin/tor+0x444018)
Indirect leak of 128 byte(s) in 1 object(s) allocated from:
#0 0x4eb568 in malloc (/usr/bin/tor+0x4eb568)
#1 0x9fbc6b in tor_malloc_ /tmp/portage/net-misc/tor-0.2.7.6/work/tor-0.2.7.6/src/common/util.c:171:12
#2 0x9fc050 in tor_malloc_zero_ /tmp/portage/net-misc/tor-0.2.7.6/work/tor-0.2.7.6/src/common/util.c:197:18
#3 0x9fc050 in tor_calloc_ /tmp/portage/net-misc/tor-0.2.7.6/work/tor-0.2.7.6/src/common/util.c:235
#4 0x9c7c0d in smartlist_new /tmp/portage/net-misc/tor-0.2.7.6/work/tor-0.2.7.6/src/common/container.c:37:14
#5 0x7e73fe in options_init_from_string /tmp/portage/net-misc/tor-0.2.7.6/work/tor-0.2.7.6/src/or/config.c:4720:7
#6 0x7e4f09 in options_init_from_torrc /tmp/portage/net-misc/tor-0.2.7.6/work/tor-0.2.7.6/src/or/config.c:4524:12
#7 0x52cf11 in tor_init /tmp/portage/net-misc/tor-0.2.7.6/work/tor-0.2.7.6/src/or/main.c:2709:7
#8 0x52e2a6 in tor_main /tmp/portage/net-misc/tor-0.2.7.6/work/tor-0.2.7.6/src/or/main.c:3271:7
#9 0x51c51d in main /tmp/portage/net-misc/tor-0.2.7.6/work/tor-0.2.7.6/src/or/tor_main.c:30:11
#10 0x444018 in _start (/usr/bin/tor+0x444018)
SUMMARY: AddressSanitizer: 144 byte(s) leaked in 2 allocation(s).
**Trac**:
**Username**: asarubboTor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/11649Memory leak when parsing broken microdescriptors2020-06-13T14:35:56ZNick MathewsonMemory leak when parsing broken microdescriptorsWhen we're parsing microdescriptors, we don't clear the dynamically allocated part of the tokens after parsing. This can leak memory if the microdescriptors are badly formed.
This can enable a comparatively slow denial of service (on t...When we're parsing microdescriptors, we don't clear the dynamically allocated part of the tokens after parsing. This can leak memory if the microdescriptors are badly formed.
This can enable a comparatively slow denial of service (on the order of several MB per MD download request made to a hostile source), and needs to be patched.
Found as a needle in the haystack of #11618.Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/9916Gradually increasing memory usage on relay2020-06-13T14:32:23ZTracGradually increasing memory usage on relayRunning tor 0.2.3.25 (installed from the tor apt repo) as a relay on a debian squeeze VPS, and I notice a pattern of continuously increasing memory usage until it eats up all available ram and my VPS gets auto-rebooted by the host's main...Running tor 0.2.3.25 (installed from the tor apt repo) as a relay on a debian squeeze VPS, and I notice a pattern of continuously increasing memory usage until it eats up all available ram and my VPS gets auto-rebooted by the host's maintenance scripts. Seems like there's a memory leak somewhere.
The VPS has 300MB of allocated ram. It takes roughly 3-5 days between reboots.
The relay is set with RelayBandwidthRate 150 KB, and RelayBandwidthBurst 300 KB.
I'd be happy to provide any other details necessary to help fix this problem.
**Trac**:
**Username**: PB8iEL6NZhk4Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/9082Memory leak when channel is closed before sending destroy cells2020-06-13T14:29:50ZNick MathewsonMemory leak when channel is closed before sending destroy cellsOn IRC, skruffy reports that the #7912 fix doesn't actually remove or free entries in the channel,circid->circuit map when those entries were added by channel_mark_circid_unusable.On IRC, skruffy reports that the #7912 fix doesn't actually remove or free entries in the channel,circid->circuit map when those entries were added by channel_mark_circid_unusable.Tor: 0.2.5.x-final