Thanks, Kuba, exactly this issue!

Best Regards,
Hongxu


On Mon, Dec 31, 2018 at 10:43 AM Kuba Mracek <[email protected]> wrote:

> > 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].
> For more options, visit 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