[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: heap-use-after-free in object_ref_cleanup

From: Orivej Desh <orivej_at_gmx.fr>
Date: Mon, 29 May 2017 02:56:26 +0000

* 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

This is an archived mail posted to the Subversion Dev mailing list.