* Daniel Shahaf <d.s_at_daniel.shahaf.name> [2017-05-23]
>
> The report says that the use-after-free occured inside the cleanup handler. It
> doesn't say where the accessed object was allocated or freed; to get that info,
> you'd have had to compile APR with pool debugging (--enable-pool-debug), then
> the second and third traceback would have pointed to the site of the malloc()
> and of the apr_pool_clear().
Thanks for your response! I did not make much progress: I know that
--config-file option is necessary for reproduction, that actual config
file is irrelevant (may be empty), and here is the ASAN report from
subversion r1796426 and apr 1.6.0 with -DAPR_POOL_DEBUG=13 (I replaced
path prefixes with // for convenience).
> The pool cleanup is registered in add_object_ref(). Can you break in that
> function and confirm which of its two callsites is involved?
When I comment out `add_object_ref' in `lookup' the bug remains, but
when I delete it from `insert' svnserve exits successfully.
==456372==ERROR: AddressSanitizer: heap-use-after-free on address 0x60600000ea80 at pc 0x00000097c7c9 bp 0x7fff2ae32eb0 sp 0x7fff2ae32ea8
READ of size 8 at 0x60600000ea80 thread T0
#0 0x97c7c8 in object_ref_cleanup //subversion/subversion/libsvn_subr/object_pool.c:144:45
#1 0x640010 in run_cleanups //apr/memory/unix/apr_pools.c:2629:9
#2 0x63bbb1 in pool_clear_debug //apr/memory/unix/apr_pools.c:1830:5
#3 0x63c0a8 in pool_destroy_debug //apr/memory/unix/apr_pools.c:1915:5
#4 0x63b1ed in apr_pool_destroy_debug //apr/memory/unix/apr_pools.c:1957:5
#5 0x63fdae in apr_pool_destroy //apr/memory/unix/apr_pools.c:2887:5
#6 0x5c0d15 in main //subversion/subversion/svnserve/svnserve.c:1432:3
#7 0x7f22c12d682f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
#8 0x4f2c78 in _start (/home/orivej/bin/svnserve+0x4f2c78)
0x60600000ea80 is located 0 bytes inside of 56-byte region [0x60600000ea80,0x60600000eab8)
freed by thread T0 here:
#0 0x59114b in free //compiler-rt/lib/asan/asan_malloc_linux.cc:47:3
#1 0x63bf6c in pool_clear_debug //apr/memory/unix/apr_pools.c:1853:13
#2 0x63c0a8 in pool_destroy_debug //apr/memory/unix/apr_pools.c:1915:5
#3 0x63bb9c in pool_clear_debug //apr/memory/unix/apr_pools.c:1827:9
#4 0x63c0a8 in pool_destroy_debug //apr/memory/unix/apr_pools.c:1915:5
#5 0x63b1ed in apr_pool_destroy_debug //apr/memory/unix/apr_pools.c:1957:5
#6 0x63fdae in apr_pool_destroy //apr/memory/unix/apr_pools.c:2887:5
#7 0x5c0d15 in main //subversion/subversion/svnserve/svnserve.c:1432:3
#8 0x7f22c12d682f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
previously allocated by thread T0 here:
#0 0x59149c in malloc //compiler-rt/lib/asan/asan_malloc_linux.cc:64:3
#1 0x63b31b in pool_alloc //apr/memory/unix/apr_pools.c:1740:16
#2 0x63b229 in apr_palloc_debug //apr/memory/unix/apr_pools.c:1781:11
#3 0x63fd26 in apr_palloc //apr/memory/unix/apr_pools.c:2863:12
#4 0x97c214 in insert //subversion/subversion/libsvn_subr/object_pool.c:230:20
#5 0x97c0d6 in svn_object_pool__insert //subversion/subversion/libsvn_subr/object_pool.c:321:3
#6 0x8fc7b0 in find_config //subversion/subversion/libsvn_repos/config_pool.c:89:7
#7 0x8fc2dd in svn_repos__config_pool_get //subversion/subversion/libsvn_repos/config_pool.c:126:33
#8 0x5c340f in sub_main //subversion/subversion/svnserve/svnserve.c:1063:7
#9 0x5c0c1d in main //subversion/subversion/svnserve/svnserve.c:1411:9
#10 0x7f22c12d682f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
Received on 2017-05-29 04:56:46 CEST