Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:21:45Zhttps://gitlab.torproject.org/legacy/trac/-/issues/25174Update to February GeoIP2 database2020-06-13T15:21:45ZKarsten LoesingUpdate to February GeoIP2 database[My geoip-2018-02-07 branch](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-2018-02-07) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.5 and all other re...[My geoip-2018-02-07 branch](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-2018-02-07) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.5 and all other relevant branches.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/24825Update to January GeoIP2 database2020-06-13T15:20:02ZKarsten LoesingUpdate to January GeoIP2 database[My geoip-2018-01-05 branch](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-2018-01-05) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.5 and all other re...[My geoip-2018-01-05 branch](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-2018-01-05) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.5 and all other relevant branches.
(I'm never sure what to pick for milestone and keywords here, so I'm copying those fields from past tickets. Please update those fields if you want me to fill in different versions in future tickets. Thanks!)Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/24690Update to December GeoIP2 database2020-06-13T15:19:17ZKarsten LoesingUpdate to December GeoIP2 database[My geoip-2017-12-06 branch](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-2017-12-06) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.5 and all other re...[My geoip-2017-12-06 branch](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-2017-12-06) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.5 and all other relevant branches.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/24220Update to November GeoIP2 database2020-06-13T15:17:12ZKarsten LoesingUpdate to November GeoIP2 database[My geoip-2017-11-06 branch](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-2017-11-06) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.5 and all other re...[My geoip-2017-11-06 branch](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-2017-11-06) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.5 and all other relevant branches.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/23773Update to October GeoIP2 database2020-06-13T15:15:18ZKarsten LoesingUpdate to October GeoIP2 database[geoip-oct2017](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-oct2017) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.5 and all other relevant branches.[geoip-oct2017](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-oct2017) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.5 and all other relevant branches.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/23430Update to September GeoIP2 database2020-06-13T15:13:24ZKarsten LoesingUpdate to September GeoIP2 database[geoip-sep2017](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-sep2017) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.5 and all other relevant branches.[geoip-sep2017](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-sep2017) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.5 and all other relevant branches.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/23093Update to August GeoIP2 database2020-06-13T15:12:17ZKarsten LoesingUpdate to August GeoIP2 database[geoip-aug2017](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-aug2017) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.5 and all other relevant branches.[geoip-aug2017](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-aug2017) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.5 and all other relevant branches.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/22851Update to July GeoIP2 database2020-06-13T15:11:24ZKarsten LoesingUpdate to July GeoIP2 database[geoip-jul2017](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-jul2017) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.4 and all other relevant branches.[geoip-jul2017](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-jul2017) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.4 and all other relevant branches.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/22789Tor 0.3.1.4-alpha crash on OpenBSD-current2020-06-13T15:11:01ZfredzupyTor 0.3.1.4-alpha crash on OpenBSD-currentHi,
After a few hours running, my new freshly compiled Tor 0.3.1.4-alpha has crashed with this message in log :
Jul 1 05:06:47 ethnao Tor[94685]: tor_assertion_failed_(): Bug: src/common/compat.c:2597: tor_inet_pton: Assertion next !...Hi,
After a few hours running, my new freshly compiled Tor 0.3.1.4-alpha has crashed with this message in log :
Jul 1 05:06:47 ethnao Tor[94685]: tor_assertion_failed_(): Bug: src/common/compat.c:2597: tor_inet_pton: Assertion next != src failed; aborting. (on Tor 0.3.1.4-alpha fab91a290ded3e74)
Jul 1 05:06:47 ethnao Tor[94685]: Bug: Assertion next != src failed in tor_inet_pton at src/common/compat.c:2597. (Stack trace not available) (on Tor 0.3.1.4-alpha fab91a290ded3e74)
Things I've done before :
$ ./configure
$ make
$ make test
$ doas src/or/tor -f /etc/tor/torrc
Then put some load on the Tor process with some random http request.
Logs with context :
Jul 1 05:06:02 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $0DA9BD201766EDB19F57F49F1A013A8A5432C008~PhantomTrain4 at 65.19.167.131. Retrying on a new circuit.
Jul 1 05:06:03 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $0DA9BD201766EDB19F57F49F1A013A8A5432C008~PhantomTrain4 at 65.19.167.131. Retrying on a new circuit.
Jul 1 05:06:04 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $0DA9BD201766EDB19F57F49F1A013A8A5432C008~PhantomTrain4 at 65.19.167.131. Retrying on a new circuit.
Jul 1 05:06:07 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $379FB450010D17078B3766C2273303C358C3A442~aurora at 176.126.252.12. Retrying on a new circuit.
Jul 1 05:06:11 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $379FB450010D17078B3766C2273303C358C3A442~aurora at 176.126.252.12. Retrying on a new circuit.
Jul 1 05:06:12 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $379FB450010D17078B3766C2273303C358C3A442~aurora at 176.126.252.12. Retrying on a new circuit.
Jul 1 05:06:15 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $379FB450010D17078B3766C2273303C358C3A442~aurora at 176.126.252.12. Retrying on a new circuit.
Jul 1 05:06:17 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $379FB450010D17078B3766C2273303C358C3A442~aurora at 176.126.252.12. Retrying on a new circuit.
Jul 1 05:06:17 ethnao Tor[94685]: Tried for 133 seconds to get a connection to [scrubbed]:80. Giving up.
Jul 1 05:06:18 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $379FB450010D17078B3766C2273303C358C3A442~aurora at 176.126.252.12. Retrying on a new circuit.
Jul 1 05:06:18 ethnao Tor[94685]: Tried for 125 seconds to get a connection to [scrubbed]:80. Giving up.
Jul 1 05:06:19 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $379FB450010D17078B3766C2273303C358C3A442~aurora at 176.126.252.12. Retrying on a new circuit.
Jul 1 05:06:21 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $14F92FF956105932E9DEC5B82A7778A0B1BD9A52~hessel0 at 109.163.234.2. Retrying on a new circuit.
Jul 1 05:06:22 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $14F92FF956105932E9DEC5B82A7778A0B1BD9A52~hessel0 at 109.163.234.2. Retrying on a new circuit.
Jul 1 05:06:22 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $14F92FF956105932E9DEC5B82A7778A0B1BD9A52~hessel0 at 109.163.234.2. Retrying on a new circuit.
Jul 1 05:06:26 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $14F92FF956105932E9DEC5B82A7778A0B1BD9A52~hessel0 at 109.163.234.2. Retrying on a new circuit.
Jul 1 05:06:27 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $14F92FF956105932E9DEC5B82A7778A0B1BD9A52~hessel0 at 109.163.234.2. Retrying on a new circuit.
Jul 1 05:06:30 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $14F92FF956105932E9DEC5B82A7778A0B1BD9A52~hessel0 at 109.163.234.2. Retrying on a new circuit.
Jul 1 05:06:34 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $14F92FF956105932E9DEC5B82A7778A0B1BD9A52~hessel0 at 109.163.234.2. Retrying on a new circuit.
Jul 1 05:06:36 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $E444FE133F55B6FFD338337AA42BA199581E2C4B~spacitospacito2 at 51.15.52.230. Retrying on a new circuit.
Jul 1 05:06:38 ethnao Tor[94685]: We tried for 16 seconds to connect to '[scrubbed]' using exit $E444FE133F55B6FFD338337AA42BA199581E2C4B~spacitospacito2 at 51.15.52.230. Retrying on a new circuit.
Jul 1 05:06:38 ethnao Tor[94685]: We tried for 16 seconds to connect to '[scrubbed]' using exit $E444FE133F55B6FFD338337AA42BA199581E2C4B~spacitospacito2 at 51.15.52.230. Retrying on a new circuit.
Jul 1 05:06:41 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $E444FE133F55B6FFD338337AA42BA199581E2C4B~spacitospacito2 at 51.15.52.230. Retrying on a new circuit.
Jul 1 05:06:41 ethnao Tor[94685]: Tried for 125 seconds to get a connection to [scrubbed]:80. Giving up.
Jul 1 05:06:42 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $E444FE133F55B6FFD338337AA42BA199581E2C4B~spacitospacito2 at 51.15.52.230. Retrying on a new circuit.
Jul 1 05:06:45 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $E444FE133F55B6FFD338337AA42BA199581E2C4B~spacitospacito2 at 51.15.52.230. Retrying on a new circuit.
Jul 1 05:06:47 ethnao Tor[94685]: tor_assertion_failed_(): Bug: src/common/compat.c:2597: tor_inet_pton: Assertion next != src failed; aborting. (on Tor 0.3.1.4-alpha fab91a290ded3e74)
Jul 1 05:06:47 ethnao Tor[94685]: Bug: Assertion next != src failed in tor_inet_pton at src/common/compat.c:2597. (Stack trace not available) (on Tor 0.3.1.4-alpha fab91a290ded3e74)Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/22737CID 1401591: errant memset in cell_pack().2020-06-13T15:10:46ZNick MathewsonCID 1401591: errant memset in cell_pack().There's a new issue that coverity found. I believe it is harmless
in practice, and I've had other network-team member sanity-check my
analysis, but we should fix it anyway.
The issue is in cell_pack, in connection_or.c. Here is the fu...There's a new issue that coverity found. I believe it is harmless
in practice, and I've had other network-team member sanity-check my
analysis, but we should fix it anyway.
The issue is in cell_pack, in connection_or.c. Here is the function
in question (comment is added):
```
void
cell_pack(packed_cell_t *dst, const cell_t *src, int wide_circ_ids)
{
char *dest = dst->body;
if (wide_circ_ids) {
set_uint32(dest, htonl(src->circ_id));
dest += 4;
} else {
set_uint16(dest, htons(src->circ_id));
dest += 2;
memset(dest+CELL_MAX_NETWORK_SIZE-2, 0, 2); // <--- PROBLEM memset()!
}
set_uint8(dest, src->command);
memcpy(dest+1, src->payload, CELL_PAYLOAD_SIZE);
}
```
Background: the format of a cell is like this:
```
xx circuit_id;
u8 command;
u8 payload[509];
```
For a long time, circuit_id was two bytes; now it's 4 bytes
(whenever wide_circ_ids is true). When we are using wide_circ_ids,
then a packed cell is 514 bytes long; when we aren't, then a packed
cell 512 bytes long.
The packed_cell_t.body field is large enough to hold a packed cell
of maximum size (514 bytes). When we are sending a 512-byte cell,
we want the final two bytes of the cell to be cleared. That's why we
call the memset there.
But as you can see with some arithmetic, the memset is wrong: it
should come before "dest += 2", not after. This mistake causes it
to overwrite the two bytes _after_ packed_cell_t.body.
This mistake causes two possible bugs. I believe they are both
harmless IRL.
BUG 1: memory stomping
When we call the memset, we are overwriting two 0 bytes past the end
of packed_cell_t.body. But I think that's harmless in practice,
because the definition of packed_cell_t is:
```
#define CELL_MAX_NETWORK_SIZE 514
// ...
typedef struct packed_cell_t {
TOR_SIMPLEQ_ENTRY(packed_cell_t) next;
char body[CELL_MAX_NETWORK_SIZE];
uint32_t inserted_time;
} packed_cell_t;
```
So we will overwrite either two bytes of inserted_time, or two bytes
of padding, depending on how the platform handles alignment.
If we're overwriting padding, that's safe.
If we are overwriting the inserted_time field, that's also safe: In
every case where we call cell_pack() from connection_or.c, we ignore
the inserted_time field. When we call cell_pack() from relay.c, we
don't set or use inserted_time until right after we have called
cell_pack(). SO I believe we're safe in that case too.
BUG 2: memory exposure
The original reason for this memset was to avoid the possibility of
accidentally leaking uninitialized ram to the network. Now
remember, if wide_circ_ids is false on a connection, we shouldn't
actually be sending more than 512 bytes of packed_cell_t.body, so
these two bytes can only leak to the network if there is another bug
somewhere else in the code that sends more data than is correct.
Fortunately, in relay.c, where we allocate packed_cell_t in
packed_cell_new() , we allocate it with tor_malloc_zero(), which
clears the RAM, right before we call cell_pack. So those
packed_cell_t.body bytes can't leak any information.
That leaves the two calls to cell_pack() in connection_or.c, which
use stack-alocated packed_cell_t instances.
In or_handshake_state_record_cell(), we pass the cell's contents to
crypto_digest_add_bytes(). When we do so, we get the number of
bytes to pass using the same setting of wide_circ_ids as we passed
to cell_pack(). So I believe that's safe.
In connection_or_write_cell_to_buf(), we also use the same setting
of wide_circ_ids in both calls. So I believe that's safe too.
CONCLUSION:
I think this bug can't actually leak any data or overwrite anything
of value. Still we should fix it.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/22555Update to June GeoIP2 database2020-06-13T15:10:07ZKarsten LoesingUpdate to June GeoIP2 database[geoip-jun2017](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-jun2017) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.4 and all other relevant branches.[geoip-jun2017](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-jun2017) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.4 and all other relevant branches.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/22490Stop using GeoIP country after buf has gone out of scope2020-06-13T15:09:58ZteorStop using GeoIP country after buf has gone out of scopeIn geoip_parse_entry() (IPv6 case), we find `country` in `buf`, let `buf` go out of scope, then pass `country` to geoip_add_entry().
Let's stop doing that.In geoip_parse_entry() (IPv6 case), we find `country` in `buf`, let `buf` go out of scope, then pass `country` to geoip_add_entry().
Let's stop doing that.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/22189Update to May GeoIP2 database2020-06-13T15:08:37ZKarsten LoesingUpdate to May GeoIP2 database[geoip-may2017](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-may2017) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.4 and all other relevant branches.[geoip-may2017](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-may2017) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.4 and all other relevant branches.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/21874Update to April GeoIP2 database2020-06-13T15:07:38ZKarsten LoesingUpdate to April GeoIP2 database[geoip-apr2017](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-apr2017) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.4 and all other relevant branches.[geoip-apr2017](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-apr2017) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.4 and all other relevant branches.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/21680Update to March GeoIP2 database2020-06-13T15:07:12ZKarsten LoesingUpdate to March GeoIP2 database[geoip-mar2017](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-mar2017) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.4 and all other relevant branches.[geoip-mar2017](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-mar2017) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.4 and all other relevant branches.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/21442Update to February GeoIP2 database2020-06-13T15:06:14ZKarsten LoesingUpdate to February GeoIP2 database[geoip-feb2017](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-feb2017) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.4 and all other relevant branches.[geoip-feb2017](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-feb2017) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.4 and all other relevant branches.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/21135Update to January GeoIP2 database2020-06-13T15:05:12ZKarsten LoesingUpdate to January GeoIP2 database[geoip-jan2017](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-jan2017) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.4 and all other relevant branches.[geoip-jan2017](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-jan2017) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.4 and all other relevant branches.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/21018TROVE-2016-12-002: read one byte past end of buffer in get_token()2020-06-13T15:22:56ZNick MathewsonTROVE-2016-12-002: read one byte past end of buffer in get_token()Grabbing a ticket for this issue. Severity ranked as "low" or "medium", depending on how the analysis goes.Grabbing a ticket for this issue. Severity ranked as "low" or "medium", depending on how the analysis goes.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/20933Update to December GeoIP2 database2020-06-13T15:04:15ZKarsten LoesingUpdate to December GeoIP2 database[geoip-dec2016](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-dec2016) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.4 and all other relevant branches.[geoip-dec2016](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-dec2016) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.4 and all other relevant branches.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/20716memory leak in connection_handle_listener_read()2020-06-13T15:03:34ZRoger Dingledinememory leak in connection_handle_listener_read()Running my Tor relay under valgrind with all the config options that Yawning's sandboxed Tor Browser turns on, I see:
```
==18287== 70,128 bytes in 8,766 blocks are definitely lost in loss record 64 of 64
==18287== at 0x4C28C20: mallo...Running my Tor relay under valgrind with all the config options that Yawning's sandboxed Tor Browser turns on, I see:
```
==18287== 70,128 bytes in 8,766 blocks are definitely lost in loss record 64 of 64
==18287== at 0x4C28C20: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==18287== by 0x62AF989: strdup (strdup.c:42)
==18287== by 0x26329D: tor_strdup_ (util.c:288)
==18287== by 0x251013: tor_addr_to_str_dup (address.c:1209)
==18287== by 0x202245: connection_handle_listener_read (connection.c:1598)
==18287== by 0x2025BC: connection_handle_read_impl (connection.c:3344)
==18287== by 0x14B160: conn_read_callback (main.c:694)
==18287== by 0x53613DB: event_base_loop (in /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5.1.9)
==18287== by 0x14C1E3: run_main_loop_once (main.c:2385)
==18287== by 0x14C1E3: run_main_loop_until_done (main.c:2429)
==18287== by 0x14C1E3: do_main_loop (main.c:2357)
==18287== by 0x14F934: tor_main (main.c:3486)
==18287== by 0x147AC8: main (tor_main.c:34)
```
(This is the Tor from my bug20423 branch, which is commit caf742287 from close to the edge of maint-0.2.9 plus two hopefully irrelevant commits -- so I am calling the version 0.2.9.5-alpha.)Tor: 0.2.9.x-final