Address Sanitizer report interpretation

Jonathan Mitchell <[email protected]>
Newsgroups gmane.comp.gnome.mono.general
Message-ID <[email protected]>
Hi

Xcode 7 has a new valgrind like tool called Address Sanitizer.
My OS X app links to the embedded API so this gets targeted by the tool. 

So I get a memcpy heap buffer overflow sanitation report for Mono as below and identify (I think) the call site in fill_reflection_assembly_name
It says:

0x6040007e2ef1 is located 0 bytes to the right of 33-byte region [0x6040007e2ed0,0x6040007e2ef1)
So that means that we have written 1 byte past the end of the buffer pointed to by mono_array_addr (aname->publicKey, guint8, 0)?
So either that address is incorrect or pkey_len is too long?

I am only getting started with this tool so I am not yet inclined to take everything it says at face value yet - perhaps it generates false positives.

I don’t know the guts of Mono well enough to know whether the memcpy() below looks suspect or not.

Jonathan

==================

Memcpy call site

==================

fill_reflection_assembly_name ()

...
pkey_ptr = (char*)name->public_key;
pkey_len = mono_metadata_decode_blob_size (pkey_ptr, &pkey_ptr);

MONO_OBJECT_SETREF (aname, publicKey, mono_array_new (domain, mono_defaults.byte_class, pkey_len));
memcpy (mono_array_addr (aname->publicKey, guint8, 0), pkey_ptr, pkey_len); << I think this is the overflow
aname->flags |= ASSEMBLYREF_FULL_PUBLIC_KEY_FLAG;

=======================

AddressSanitizer output

=================================================================
==19261==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6040007e2ef1 at pc 0x000100e90cf4 bp 0x700000523b20 sp 0x7000005232d8
READ of size 48 at 0x6040007e2ef1 thread T23
   #0 0x100e90cf3 in wrap_memcpy (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/7.0.0/lib/darwin/libclang_rt.asan_osx_dynamic.dylib+0x3acf3)
   #1 0x102902c3b in fill_reflection_assembly_name (/Users/jonathan/Library/Developer/Xcode/DerivedData/DummyApp-evzyclkfwllgccgdmfnxveopjbku/Build/Products/Debug/DummyApp.app/Contents/LGPL/Frameworks/Mono64.framework/Versions/4.0.4.4/lib/libmonosgen-2.0.1.dylib+0x143c3b)
   #2 0x1028fd950 in ves_icall_System_Reflection_AssemblyName_ParseName (/Users/jonathan/Library/Developer/Xcode/DerivedData/DummyApp-evzyclkfwllgccgdmfnxveopjbku/Build/Products/Debug/DummyApp.app/Contents/LGPL/Frameworks/Mono64.framework/Versions/4.0.4.4/lib/libmonosgen-2.0.1.dylib+0x13e950)
   #3 0x121727b0e  (<unknown module>)
   #4 0x12d10e6d5  (<unknown module>)
   #5 0x12d107493  (<unknown module>)
   #6 0x12d1068cc  (<unknown module>)

0x6040007e2ef1 is located 0 bytes to the right of 33-byte region [0x6040007e2ed0,0x6040007e2ef1)
allocated by thread T23 here:
   #0 0x100e9359c in wrap_strdup (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/7.0.0/lib/darwin/libclang_rt.asan_osx_dynamic.dylib+0x3d59c)
   #1 0x1028cd729 in build_assembly_name (/Users/jonathan/Library/Developer/Xcode/DerivedData/DummyApp-evzyclkfwllgccgdmfnxveopjbku/Build/Products/Debug/DummyApp.app/Contents/LGPL/Frameworks/Mono64.framework/Versions/4.0.4.4/lib/libmonosgen-2.0.1.dylib+0x10e729)
   #2 0x1028cd2a4 in mono_assembly_name_parse_full (/Users/jonathan/Library/Developer/Xcode/DerivedData/DummyApp-evzyclkfwllgccgdmfnxveopjbku/Build/Products/Debug/DummyApp.app/Contents/LGPL/Frameworks/Mono64.framework/Versions/4.0.4.4/lib/libmonosgen-2.0.1.dylib+0x10e2a4)
   #3 0x1028fd920 in ves_icall_System_Reflection_AssemblyName_ParseName (/Users/jonathan/Library/Developer/Xcode/DerivedData/DummyApp-evzyclkfwllgccgdmfnxveopjbku/Build/Products/Debug/DummyApp.app/Contents/LGPL/Frameworks/Mono64.framework/Versions/4.0.4.4/lib/libmonosgen-2.0.1.dylib+0x13e920)
   #4 0x121727b0e  (<unknown module>)
   #5 0x12d10e6d5  (<unknown module>)
   #6 0x12d107493  (<unknown module>)
   #7 0x12d1068cc  (<unknown module>)

Thread T23 created by T2 here:
   <empty stack>

Thread T2 created by T0 here:
   <empty stack>

SUMMARY: AddressSanitizer: heap-buffer-overflow ??:0 wrap_memcpy
Shadow bytes around the buggy address:
 0x1c08000fc580: fa fa fa fa fa fa fa fa fa fa 00 00 00 00 00 fa
 0x1c08000fc590: fa fa 00 00 00 00 00 00 fa fa 00 00 00 00 00 00
 0x1c08000fc5a0: fa fa 00 00 00 00 00 00 fa fa 00 00 00 00 00 00
 0x1c08000fc5b0: fa fa fd fd fd fd fd fd fa fa 00 00 00 00 00 00
 0x1c08000fc5c0: fa fa fd fd fd fd fd fd fa fa 00 00 00 00 00 00
=>0x1c08000fc5d0: fa fa 00 00 00 00 00 00 fa fa 00 00 00 00[01]fa
 0x1c08000fc5e0: fa fa fd fd fd fd fd fd fa fa 00 00 00 00 00 00
 0x1c08000fc5f0: fa fa fd fd fd fd fd fd fa fa 00 00 00 00 00 00
 0x1c08000fc600: fa fa fd fd fd fd fd fa fa fa fd fd fd fd fd fa
 0x1c08000fc610: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fa
 0x1c08000fc620: fa fa fd fd fd fd fd fa fa fa fd fd fd fd fd fa
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
 Container overflow:      fc
 Array cookie:            ac
 Intra object redzone:    bb
 ASan internal:           fe
 Left alloca redzone:     ca
 Right alloca redzone:    cb
==19261==ABORTING


Regards

Jonathan Mitchell
Mugginsoft LLP

[email protected]
-----------------------------------------------------------------------------
KosmicTask - the Integrated Scripting Environment for OS X.
http://www.mugginsoft.com/KosmicTask
-----------------------------------------------------------------------------
Follow on Twitter @KosmicTask
-----------------------------------------------------------------------------
Github http://github.com/mugginsoft












_______________________________________________
Mono-list maillist  -  [email protected]
http://lists.ximian.com/mailman/listinfo/mono-list
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.