<div dir="ltr">Moving to <a href="https://llvm.org/bugs/show_bug.cgi?id=25550">https://llvm.org/bugs/show_bug.cgi?id=25550</a></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 16, 2015 at 5:15 PM, Kostya Serebryany <span dir="ltr"><<a href="mailto:kcc@google.com" target="_blank">kcc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">BTW, this is very similar to <a href="https://github.com/google/sanitizers/issues/20" target="_blank">https://github.com/google/sanitizers/issues/20</a> (fixed long ago), <div>apparently we need to add another check to gvn, similar to the one we already have.</div><div>Or figure out why this one does not work... </div><div><br></div><div>in lib/Analysis/MemoryDependenceAnalysis.cpp:</div><div><div> 346 if (LIOffs + NewLoadByteSize > MemLocEnd &&</div><div> 347 LI->getParent()->getParent()->hasFnAttribute(</div><div> 348 Attribute::SanitizeAddress))</div><div> 349 // We will be reading past the location accessed by the original program.</div><div> 350 // While this is safe in a regular build, Address Safety analysis tools</div><div> 351 // may start reporting false warnings. So, don't do widening.</div><div> 352 return 0;</div></div><div><br></div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 16, 2015 at 4:59 PM, Kostya Serebryany <span dir="ltr"><<a href="mailto:kcc@google.com" target="_blank">kcc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Confirmed. <div><br></div><div><br></div><div>A smaller repro:</div><div><br></div><div><div>typedef union {</div><div> short q;</div><div> struct {</div><div> short x;</div><div> short y;</div><div> int for_alignment;</div><div> } w;</div><div>} U;</div><div>char *buf = new char[2];</div><div>int main() {</div><div> buf[0] = buf[1] = 0x0;</div><div> U *u = (U *)buf;</div><div> return u->q == 0 ? 0 : u->w.y;</div><div>} </div></div><div><br></div><div><br></div><div>With O2 asan produces false positive and with -O1/-O0 it does not. </div><div>One more case where an optimization is hostile to asan... </div><div>Looking. </div><div><br></div><div><br></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Nov 14, 2015 at 9:09 AM, Greg Stark <span dir="ltr"><<a href="mailto:stark@mit.edu" target="_blank">stark@mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Thu, Nov 12, 2015 at 8:42 PM, Kostya Serebryany <<a href="mailto:kcc@google.com" target="_blank">kcc@google.com</a>> wrote:<br>
> 2 questions:<br>
> - Do you see this with the fresh llvm trunk?<br>
> - Can you prepare a minimized example?<br>
<br>
</span>Pretty recent, I updated a couple days ago. I tried to minimize the<br>
attached but at the same time I didn't want to lose too many unions<br>
and casts in case it didn't trigger any more.<br>
<br>
$ clang -fsanitize=address -Wall numeric-asan-test.c<br>
$ ./a.out<br>
VARSIZE 6<br>
NDIGITS 0<br>
WEIGHT 0<br>
SIGN 0<br>
DSCALE 0<br>
$ clang -fsanitize=address -O2 -Wall numeric-asan-test.c<br>
$ ./a.out<br>
VARSIZE 6<br>
=================================================================<br>
==19982==ERROR: AddressSanitizer: heap-buffer-overflow on address<br>
0x60200000eff4 at pc 0x0000004d4986 bp 0x7ffe14e2cb90 sp<br>
0x7ffe14e2cb88<br>
READ of size 4 at 0x60200000eff4 thread T0<br>
#0 0x4d4985 in main (/home/stark/src/a.out+0x4d4985)<br>
#1 0x7f6360f40b44 in __libc_start_main<br>
/tmp/buildd/glibc-2.19/csu/libc-start.c:287<br>
#2 0x41a935 in _start (/home/stark/src/a.out+0x41a935)<br>
<br>
0x60200000eff6 is located 0 bytes to the right of 6-byte region<br>
[0x60200000eff0,0x60200000eff6)<br>
allocated by thread T0 here:<br>
#0 0x4abceb in __interceptor_malloc<br>
/home/stark/src/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:40:3<br>
#1 0x4d479e in main (/home/stark/src/a.out+0x4d479e)<br>
<br>
SUMMARY: AddressSanitizer: heap-buffer-overflow<br>
(/home/stark/src/a.out+0x4d4985) in main<br>
<span>Shadow bytes around the buggy address:<br>
</span> 0x0c047fff9da0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa<br>
0x0c047fff9db0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa<br>
0x0c047fff9dc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa<br>
0x0c047fff9dd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa<br>
0x0c047fff9de0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa<br>
=>0x0c047fff9df0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa[06]fa<br>
0x0c047fff9e00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa<br>
0x0c047fff9e10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa<br>
0x0c047fff9e20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa<br>
0x0c047fff9e30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa<br>
0x0c047fff9e40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa<br>
Shadow byte legend (one shadow byte represents 8 application bytes):<br>
Addressable: 00<br>
Partially addressable: 01 02 03 04 05 06 07<br>
Heap left redzone: fa<br>
Heap right redzone: fb<br>
Freed heap region: fd<br>
Stack left redzone: f1<br>
Stack mid redzone: f2<br>
Stack right redzone: f3<br>
Stack partial redzone: f4<br>
Stack after return: f5<br>
Stack use after scope: f8<br>
Global redzone: f9<br>
Global init order: f6<br>
Poisoned by user: f7<br>
Container overflow: fc<br>
Array cookie: ac<br>
Intra object redzone: bb<br>
ASan internal: fe<br>
Left alloca redzone: ca<br>
Right alloca redzone: cb<br>
==19982==ABORTING<br>
<span><font color="#888888"><br>
<br>
<br>
--<br>
greg<br>
</font></span></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>