Address Sanitizer report interpretation
Address Sanitizer report interpretation
- Subject: Address Sanitizer report interpretation
- From: Jonathan Mitchell <email@hidden>
- Date: Thu, 03 Dec 2015 21:15:20 +0000
Hi
Address Sanitizer looks great.
The WWDC presentation is very insightful and I comprehend what Address Sanitizer is up to (up to a point of course).
A few questions:
1. My app links to Mono, which is a complex hunk of C. Debugging this is not really my primary concern at the moment. Is there a way to limit the code modules that Address Sanitizer (AS) targets?
2. Is there such a thing as an AS false positive?
3. So I get a memcpy heap buffer overflow sanitation report for Mono as below and identify (I think) the call site.
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?
Is that a correct interpretation?
Thanks
Jonathan
==================
Memcpy call site
==================
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@hidden
-----------------------------------------------------------------------------
KosmicTask - the Integrated Scripting Environment for OS X.
http://www.mugginsoft.com/KosmicTask
-----------------------------------------------------------------------------
Follow on Twitter @KosmicTask
-----------------------------------------------------------------------------
Github http://github.com/mugginsoft
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden