> Address 0x640000001080 is a wild pointer.

One possible explanation is that this is not really a heap-buffer-overflow, but 
it’s usage of uninitialized memory. Changing the value of 
detect_stack_use_after_return affects what variables get to live on the stack 
vs. on the heap, so it’s quite possible that in one mode the uninitialized 
memory accidentally gets a reasonable value that masks the bug.

Kuba

> On Dec 30, 2018, at 5:51 AM, Hongxu Chen <[email protected]> wrote:
> 
> Hello,
> 
>   I met one weird scenario: on one test input, when I set 
> `ASAN_OPTIONS=detect_stack_use_after_return=0`, the ASAN hardened binary 
> reports heap-buffer-overflow error like:
> 
> ```
> =================================================================
> ==17440==ERROR: AddressSanitizer: heap-buffer-overflow on address 
> 0x640000001080 at pc 0x00000044970e bp 0x7ffc9fcdf4f0 sp 0x7ffc9fcdeca0
> WRITE of size 41 at 0x640000001080 thread T0
>     #0 0x44970d in __interceptor_vsnprintf 
> (/home/hongxu/FOT/igraph-asan/install/lib/igraph.harness.out+0x44970d)
>     #1 0x61c41e in igraph_i_graphml_sax_handler_error 
> /home/hongxu/FOT/igraph-asan/src/foreign-graphml.c:228:3
>     #2 0x873443 in __xmlRaiseError /home/hongxu/FOT/libxml2-asan/error.c:638:2
>     #3 0x890b39 in xmlFatalErr /home/hongxu/FOT/libxml2-asan/parser.c:542:9
>     #4 0x9005e5 in xmlParseXMLDecl 
> /home/hongxu/FOT/libxml2-asan/parser.c:10460:2
>     #5 0x90e0e5 in xmlParseTryOrFinish 
> /home/hongxu/FOT/libxml2-asan/parser.c:11257:4
>     #6 0x90ad06 in xmlParseChunk 
> /home/hongxu/FOT/libxml2-asan/parser.c:12244:13
>     #7 0x6273f7 in igraph_read_graph_graphml 
> /home/hongxu/FOT/igraph-asan/src/foreign-graphml.c:1379:3
>     #8 0x514120 in main 
> (/home/hongxu/FOT/igraph-asan/install/lib/igraph.harness.out+0x514120)
>     #9 0x7fcd6e996b96 in __libc_start_main 
> /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310
>     #10 0x41baf9 in _start 
> (/home/hongxu/FOT/igraph-asan/install/lib/igraph.harness.out+0x41baf9)
> 
> Address 0x640000001080 is a wild pointer.
> SUMMARY: AddressSanitizer: heap-buffer-overflow 
> (/home/hongxu/FOT/igraph-asan/install/lib/igraph.harness.out+0x44970d) in 
> __interceptor_vsnprintf
> Shadow bytes around the buggy address:
>   0x0c807fff81c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c807fff81d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c807fff81e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c807fff81f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c807fff8200: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> =>0x0c807fff8210:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c807fff8220: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c807fff8230: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c807fff8240: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c807fff8250: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c807fff8260: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 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
>   Freed heap region:       fd
>   Stack left redzone:      f1
>   Stack mid redzone:       f2
>   Stack right redzone:     f3
>   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
> ==17440==ABORTING
> [1]    17440 abort      ~/FOT/igraph-asan/install/lib/igraph.harness.out
> ```
> 
> However when `detect_stack_use_after_return=1`, there is no crash report at 
> all.
> 
> I will debug with the input to see the exact root cause of the crash; and if 
> required, I can reveal the details about this case. For now, I'm quite 
> interesting why this happens? Any clues?
> 
> Best Regards,
> Hongxu
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "address-sanitizer" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to [email protected] 
> <mailto:[email protected]>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"address-sanitizer" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to