Re: heap-use-after-free in object_ref_cleanup

On 23.05.2017 10:20, Orivej Desh wrote:
> Hello,
>
> I noticed in dmesg that in my repository svnserve occasionally crashes.
> This happens at exit, so it is not visible to end users. I captured a
> few sessions at the svn protocol level that resulted in a crash; client
> commands are quite different in each one; sending an input that crashed
> `svnserve -t` again always crashes it; I did not manage to reproduce
> this in a new repository. I tested with subversion 1.9.0, 1.9.4 and
> subversion trunk, apr 1.3.0 and apr 1.5.2 with the same result.
>
> Here is the AddressSanitizer report of the problem (with subversion
> 1.9.4 and apr 1.3.0). For me it seems that a piece of memory belonging
> to the object_pool is registered for run_cleanups in the main pool, then
> right before return from main() all child pools of the main pool are
> destroyed, then run_cleanups of the main pool calls object_ref_cleanup
> with a pointer to a freed memory. Is this correct? How is this
> supposed to work? Could you help me spot the difference between
> expected and unexpected paths of code concerning the issue?

Hi Orivej,

thanks for reporting this!

The callstacks suggests that this is a pool cleanup race.
Please try the attached patch and report the results.

Thanks you!

-- Stefan^2.

>
> ==329484==ERROR: AddressSanitizer: heap-use-after-free on address 0x6250000234d0 at pc 0x00000077f3f9 bp 0x7ffc53dac920 sp 0x7ffc53dac918
> READ of size 8 at 0x6250000234d0 thread T0
> #0 0x77f3f8 in object_ref_cleanup /home/orivej/src/subversion/subversion/libsvn_subr/object_pool.c:148:45
> #1 0x9b7dd0 in run_cleanups /home/orivej/src/apr/memory/unix/apr_pools.c:2298:9
> #2 0x9b66e4 in apr_pool_destroy /home/orivej/src/apr/memory/unix/apr_pools.c:783:5
> #3 0x5bbb65 in main /home/orivej/src/subversion/subversion/svnserve/svnserve.c:1368:3
> #4 0x7f59a0f5882f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
> #5 0x4edac8 in _start (/home/orivej/bin/svnserve+0x4edac8)
>
> 0x6250000234d0 is located 976 bytes inside of 8192-byte region [0x625000023100,0x625000025100)
> freed by thread T0 here:
> #0 0x58bf9b in free /home/orivej/src/compiler-rt/lib/asan/asan_malloc_linux.cc:47:3
> #1 0x9b5991 in allocator_free /home/orivej/src/apr/memory/unix/apr_pools.c:407:9
> #2 0x9b6a4f in apr_pool_destroy /home/orivej/src/apr/memory/unix/apr_pools.c:825:5
> #3 0x9b66cf in apr_pool_destroy /home/orivej/src/apr/memory/unix/apr_pools.c:780:9
> #4 0x5bbb65 in main /home/orivej/src/subversion/subversion/svnserve/svnserve.c:1368:3
> #5 0x7f59a0f5882f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
>
> previously allocated by thread T0 here:
> #0 0x58c2ec in malloc /home/orivej/src/compiler-rt/lib/asan/asan_malloc_linux.cc:64:3
> #1 0x9b516e in allocator_alloc /home/orivej/src/apr/memory/unix/apr_pools.c:330:17
> #2 0x9b5d5a in apr_pool_create_ex /home/orivej/src/apr/memory/unix/apr_pools.c:860:17
> #3 0x62986e in svn_pool_create_ex /home/orivej/src/subversion/subversion/libsvn_subr/pool.c:70:3
> #4 0x77e654 in svn_object_pool__new_wrapper_pool /home/orivej/src/subversion/subversion/libsvn_subr/object_pool.c:356:10
> #5 0x6f04ae in auto_parse /home/orivej/src/subversion/subversion/libsvn_repos/config_pool.c:215:14
> #6 0x6eeab1 in svn_repos__config_pool_get /home/orivej/src/subversion/subversion/libsvn_repos/config_pool.c:523:17
> #7 0x5be05c in sub_main /home/orivej/src/subversion/subversion/svnserve/svnserve.c:1002:7
> #8 0x5bba6d in main /home/orivej/src/subversion/subversion/svnserve/svnserve.c:1347:9
> #9 0x7f59a0f5882f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
>