Re: Invalid memory reads in first_non_fsm_start_char_cstring (utf_validate.c)

On Sun, 3 Jan 2016 18:12:47 +0100
Branko Čibej <brane_at_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: hanno_at_hboeck.de
GPG: BBB51E42