[llvm-dev] Inexplicable ASAN report. Code generation bug?

Mon Nov 16 17:52:06 PST 2015

Moving to https://llvm.org/bugs/show_bug.cgi?id=25550

On Mon, Nov 16, 2015 at 5:15 PM, Kostya Serebryany <kcc at google.com> wrote:

> BTW, this is very similar to
> https://github.com/google/sanitizers/issues/20 (fixed long ago),
> apparently we need to add another check to gvn, similar to the one we
> already have.
> Or figure out why this one does not work...
>
> in lib/Analysis/MemoryDependenceAnalysis.cpp:
>  346     if (LIOffs + NewLoadByteSize > MemLocEnd &&
>  347         LI->getParent()->getParent()->hasFnAttribute(
>  348             Attribute::SanitizeAddress))
>  349       // We will be reading past the location accessed by the
> original program.
>  350       // While this is safe in a regular build, Address Safety
> analysis tools
>  351       // may start reporting false warnings. So, don't do widening.
>  352       return 0;
>
>
>
> On Mon, Nov 16, 2015 at 4:59 PM, Kostya Serebryany <kcc at google.com> wrote:
>
>> Confirmed.
>>
>>
>> A smaller repro:
>>
>> typedef union {
>>   short q;
>>   struct {
>>     short x;
>>     short y;
>>     int for_alignment;
>>   } w;
>> } U;
>> char *buf = new char[2];
>> int main() {
>>   buf[0] = buf[1] = 0x0;
>>   U *u = (U *)buf;
>>   return  u->q == 0 ? 0 : u->w.y;
>> }
>>
>>
>> With O2 asan produces false positive and with -O1/-O0 it does not.
>> One more case where an optimization is hostile to asan...
>> Looking.
>>
>>
>>
>> On Sat, Nov 14, 2015 at 9:09 AM, Greg Stark <stark at mit.edu> wrote:
>>
>>> On Thu, Nov 12, 2015 at 8:42 PM, Kostya Serebryany <kcc at google.com>
>>> wrote:
>>> > 2 questions:
>>> > - Do you see this with the fresh llvm trunk?
>>> > - Can you prepare a minimized example?
>>>
>>> Pretty recent, I updated a couple days ago. I tried to minimize the
>>> attached but at the same time I didn't want to lose too many unions
>>> and casts in case it didn't trigger any more.
>>>
>>> $ clang -fsanitize=address  -Wall numeric-asan-test.c
>>> $ ./a.out
>>> VARSIZE 6
>>> NDIGITS 0
>>> WEIGHT 0
>>> SIGN 0
>>> DSCALE 0
>>> $ clang -fsanitize=address -O2  -Wall numeric-asan-test.c
>>> $ ./a.out
>>> VARSIZE 6
>>> =================================================================
>>> ==19982==ERROR: AddressSanitizer: heap-buffer-overflow on address
>>> 0x60200000eff4 at pc 0x0000004d4986 bp 0x7ffe14e2cb90 sp
>>> 0x7ffe14e2cb88
>>> READ of size 4 at 0x60200000eff4 thread T0
>>>     #0 0x4d4985 in main (/home/stark/src/a.out+0x4d4985)
>>>     #1 0x7f6360f40b44 in __libc_start_main
>>> /tmp/buildd/glibc-2.19/csu/libc-start.c:287
>>>     #2 0x41a935 in _start (/home/stark/src/a.out+0x41a935)
>>>
>>> 0x60200000eff6 is located 0 bytes to the right of 6-byte region
>>> [0x60200000eff0,0x60200000eff6)
>>> allocated by thread T0 here:
>>>     #0 0x4abceb in __interceptor_malloc
>>>
>>> /home/stark/src/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:40:3
>>>     #1 0x4d479e in main (/home/stark/src/a.out+0x4d479e)
>>>
>>> SUMMARY: AddressSanitizer: heap-buffer-overflow
>>> (/home/stark/src/a.out+0x4d4985) in main
>>> Shadow bytes around the buggy address:
>>>   0x0c047fff9da0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>>>   0x0c047fff9db0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>>>   0x0c047fff9dc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>>>   0x0c047fff9dd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>>>   0x0c047fff9de0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>>> =>0x0c047fff9df0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa[06]fa
>>>   0x0c047fff9e00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>>>   0x0c047fff9e10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>>>   0x0c047fff9e20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>>>   0x0c047fff9e30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>>>   0x0c047fff9e40: 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
>>>   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
>>> ==19982==ABORTING
>>>
>>>
>>>
>>> --
>>> greg
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151116/281276e5/attachment-0001.html>