On Sun, 3 Jan 2016 18:12:47 +0100 Branko Čibej <br...@apache.org> wrote:
> GCC (or any other compiler) may do a lot of things, but it's not
> allowed to change the way APR pool allocation works. We're not using
> malloc(); we're using apr_palloc() & co.
Okay, I think we have a misunderstanding here.
The error I encountered is not by code allocated by apr_palloc. It
actually comes from this line in notify.c:
SVN_ERR(svn_dirent_get_absolute(&nb->path_prefix, "", pool));
The memory that is read out of bounds is the "" string literal.
I have pasted the address sanitizer trace below.
==29553==ERROR: AddressSanitizer: global-buffer-overflow on address
0x00000046a360 at pc 0x7f70c17916b4 bp 0x7fffcbe44ab0 sp 0x7fffcbe44aa0
READ of size 8 at 0x00000046a360 thread T0
#0 0x7f70c17916b3 in first_non_fsm_start_char_cstring
subversion/libsvn_subr/utf_validate.c:321
#1 0x7f70c1791945 in svn_utf__cstring_is_valid
subversion/libsvn_subr/utf_validate.c:367
#2 0x7f70c1788cf6 in check_cstring_utf8 subversion/libsvn_subr/utf.c:675
#3 0x7f70c178a5e4 in svn_utf_cstring_from_utf8
subversion/libsvn_subr/utf.c:901
#4 0x7f70c1743766 in svn_path_cstring_from_utf8
subversion/libsvn_subr/path.c:1141
#5 0x7f70c16ffde9 in svn_dirent_get_absolute
subversion/libsvn_subr/dirent_uri.c:1598
#6 0x43e444 in svn_cl__get_notifier subversion/svn/notify.c:1123
#7 0x453a29 in sub_main subversion/svn/svn.c:2932
#8 0x454542 in main subversion/svn/svn.c:3126
#9 0x7f70c030d62f in __libc_start_main (/lib64/libc.so.6+0x2062f)
#10 0x4071c8 in _start
(/mnt/ram/subversion-1.9.3/subversion/svn/.libs/svn+0x4071c8)
0x00000046a361 is located 0 bytes to the right of global variable '*.LC0' from
'subversion/svn/notify.c' (0x46a360) of size 1
'*.LC0' is ascii string ''
SUMMARY: AddressSanitizer: global-buffer-overflow
subversion/libsvn_subr/utf_validate.c:321 first_non_fsm_start_char_cstring
Shadow bytes around the buggy address:
0x000080085410: f9 f9 f9 f9 00 03 f9 f9 f9 f9 f9 f9 00 00 00 00
0x000080085420: 00 00 04 f9 f9 f9 f9 f9 00 00 00 00 03 f9 f9 f9
0x000080085430: f9 f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 02
0x000080085440: f9 f9 f9 f9 00 00 00 00 00 00 00 04 f9 f9 f9 f9
0x000080085450: 00 03 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00
=>0x000080085460: 00 06 f9 f9 f9 f9 f9 f9 00 00 00 00[01]f9 f9 f9
0x000080085470: f9 f9 f9 f9 00 05 f9 f9 f9 f9 f9 f9 00 03 f9 f9
0x000080085480: f9 f9 f9 f9 00 00 00 f9 f9 f9 f9 f9 00 00 07 f9
0x000080085490: f9 f9 f9 f9 00 00 00 f9 f9 f9 f9 f9 00 00 06 f9
0x0000800854a0: f9 f9 f9 f9 00 00 00 02 f9 f9 f9 f9 00 00 06 f9
0x0000800854b0: f9 f9 f9 f9 00 00 00 03 f9 f9 f9 f9 00 00 00 07
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Heap right redzone: fb
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack partial redzone: f4
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Contiguous container OOB:fc
ASan internal: fe
==29553==ABORTING
--
Hanno Böck
http://hboeck.de/
mail/jabber: ha...@hboeck.de
GPG: BBB51E42
pgpMLLrPZ1h3d.pgp
Description: OpenPGP digital signature
