Opened 10 months ago

Closed 9 months ago

#21161 closed defect (not a bug)

Invalid free() when a hidden service is configured, to a hostname destination, but we have no network

Reported by: arma Owned by:
Priority: Medium Milestone: Tor: 0.3.0.x-final
Component: Core Tor/Tor Version: Tor: 0.3.0.1-alpha
Severity: Normal Keywords:
Cc: weasel Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Set up your Tor to offer a hidden service, and use a hostname destination, like localhost:80, on the HiddenServicePort line.

Then ifdown eth0 so you have no network.

Then run valgrind tor --verify-config

and voila, you get this complaint:

Configuration was valid
==31082== Invalid free() / delete / delete[] / realloc()
==31082==    at 0x4C29E90: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==31082==    by 0x63A116B: __libc_freeres (in /lib/x86_64-linux-gnu/libc-2.19.so)
==31082==    by 0x4A236CC: _vgnU_freeres (in /usr/lib/valgrind/vgpreload_core-amd64-linux.so)
==31082==    by 0x628CAEA: __run_exit_handlers (exit.c:97)
==31082==    by 0x628CB74: exit (exit.c:104)
==31082==    by 0x6276B4B: (below main) (libc-start.c:321)
==31082==  Address 0x65fa2d0 is 0 bytes inside data symbol "noai6ai_cached"

If you leave off the --verify-config, you can trigger the same thing, by starting, and then after a while ctrl-C'ing your Tor so it exits, at which point you get something similar:

==8895== Invalid free() / delete / delete[] / realloc()
==8895==    at 0x4C29E90: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8895==    by 0x63A116B: __libc_freeres (in /lib/x86_64-linux-gnu/libc-2.19.so)
==8895==    by 0x4A236CC: _vgnU_freeres (in /usr/lib/valgrind/vgpreload_core-amd64-linux.so)
==8895==    by 0x628CAEA: __run_exit_handlers (exit.c:97)
==8895==    by 0x628CB74: exit (exit.c:104)
==8895==    by 0x154686: process_signal (main.c:2601)
==8895==    by 0x154686: signal_callback (main.c:2583)
==8895==    by 0x5361A14: event_base_loop (in /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5.1.9)
==8895==    by 0x152B53: run_main_loop_once (main.c:2514)
==8895==    by 0x152B53: run_main_loop_until_done (main.c:2568)
==8895==    by 0x152B53: do_main_loop (main.c:2481)
==8895==    by 0x1562B4: tor_main (main.c:3628)
==8895==    by 0x14E408: main (tor_main.c:34)
==8895==  Address 0x65fa2d0 is 0 bytes inside data symbol "noai6ai_cached"

It's not clear to me what is going wrong.

Child Tickets

Change History (7)

comment:1 Changed 10 months ago by arma

weasel found it in 0.2.5.12, and I confirmed it there, and then confirmed it in master too. (The above traces are from master.)

comment:2 Changed 10 months ago by weasel

Cc: weasel added

comment:3 in reply to:  description Changed 10 months ago by arma

Replying to arma:

It's not clear to me what is going wrong.

See also https://bugzilla.redhat.com/show_bug.cgi?id=754026

comment:4 Changed 10 months ago by asn

Didn't manage to reproduce this one with the following config:

SocksPort auto
ControlPort auto

HiddenServiceDir /home/user/hidden_service
HiddenServicePort 6667 localhost:6667

and no network interface.

I just get "Configuration was valid" and valgrind finishes fine:

$ valgrind ./src/or/tor -f ../confs/bug21161  --verify-config
==2308== Memcheck, a memory error detector
==2308== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==2308== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==2308== Command: ./src/or/tor -f ../confs/bug21161 --verify-config
==2308== 
Jan 09 14:27:20.019 [notice] Tor 0.3.0.1-alpha-dev (git-655ffeadd53833d9) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1t and Zlib 1.2.8.
Jan 09 14:27:20.060 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Jan 09 14:27:20.061 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Jan 09 14:27:20.073 [notice] Read configuration file "/home/f/Computers/tor/mytor/../confs/bug21161".
Configuration was valid
==2308== 
==2308== HEAP SUMMARY:
==2308==     in use at exit: 73 bytes in 2 blocks
==2308==   total heap usage: 8,654 allocs, 8,652 frees, 512,960 bytes allocated
==2308== 
==2308== LEAK SUMMARY:
==2308==    definitely lost: 28 bytes in 1 blocks
==2308==    indirectly lost: 0 bytes in 0 blocks
==2308==      possibly lost: 0 bytes in 0 blocks
==2308==    still reachable: 45 bytes in 1 blocks
==2308==         suppressed: 0 bytes in 0 blocks
==2308== Rerun with --leak-check=full to see details of leaked memory
==2308== 
==2308== For counts of detected and suppressed errors, rerun with: -v
==2308== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Last edited 10 months ago by asn (previous) (diff)

comment:5 Changed 10 months ago by arma

I'm on some sort of Debian stable like system.

Are you on something different?

Could this be a bug in Debian's glibc?

comment:6 Changed 9 months ago by nickm

noai6ai_cached makes me think this is a glibc/getaddrinfo bug, and so does https://bugzilla.redhat.com/show_bug.cgi?id=754026

comment:7 Changed 9 months ago by nickm

Resolution: not a bug
Status: newclosed

Closing this as not-a-bug, since it appears to be an old glibc issue. But please reopen if I am wrong.

Note: See TracTickets for help on using tickets.