[Mono-list] Address Sanitizer report interpretation

Jonathan Mitchell jonathan at mugginsoft.com
Thu Dec 3 21:23:47 UTC 2015


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

jonathan at mugginsoft.com
-----------------------------------------------------------------------------
KosmicTask - the Integrated Scripting Environment for OS X.
http://www.mugginsoft.com/KosmicTask
-----------------------------------------------------------------------------
Follow on Twitter @KosmicTask
-----------------------------------------------------------------------------
Github http://github.com/mugginsoft














More information about the Mono-list mailing list