Greg Stark via llvm-dev
2015-Nov-14 17:09 UTC
[llvm-dev] Inexplicable ASAN report. Code generation bug?
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 -------------- A non-text attachment was scrubbed... Name: numeric-asan-test.c Type: text/x-csrc Size: 4464 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151114/1c7d8dbe/attachment.c>
Kostya Serebryany via llvm-dev
2015-Nov-17 00:59 UTC
[llvm-dev] Inexplicable ASAN report. Code generation bug?
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/d65c5efc/attachment.html>
Kostya Serebryany via llvm-dev
2015-Nov-17 01:15 UTC
[llvm-dev] Inexplicable ASAN report. Code generation bug?
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/224d8a9c/attachment.html>