Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue with -faddress-sanitizer in combination with -Os/-O2 #20

Closed
GoogleCodeExporter opened this issue Aug 5, 2015 · 7 comments
Closed

Comments

@GoogleCodeExporter
Copy link

I recently tried a Firefox+ASan build with optimization turned on. During 
startup I saw an ASan abort due to a stack buffer overflow in libpng code 
(which only happens in the optimized version). I inspected the code and it's 
impossible that an overflow is happening at the given location.

However, I managed to extract a testcase and minimized it by automatic means 
with respect to code and involved compiler flags. It turned out that the 
combination of -faddress-sanitizer and -Os is the problem, -O2 produces the 
same. Using -O1 or -O0 though works. The test is attached: To reproduce, unpack 
the archive, run "make" and then execute ./main.

Tested this on 64 bit with LLVM/Clang/compiler-rt revision 146212.


Main output is:

==25258== ERROR: AddressSanitizer stack-buffer-overflow on address 
0x7fff94e82cb0 at pc 0x4019ff bp 0x7fff94e82c50 sp 0x7fff94e82c48
READ of size 8 at 0x7fff94e82cb0 thread T0
    #0 0x4019ff (testAsanOptimizeSize/main+0x4019ff)
    #1 0x401929 (testAsanOptimizeSize/main+0x401929)
    #2 0x7f76bd049eff (/lib/x86_64-linux-gnu/libc-2.13.so+0x1eeff)
Address 0x7fff94e82cb0 is located at offset 48 in frame <test> of T0's stack:
  This frame has 1 object(s):
    [32, 54) 'data'


The function init just initializes the buffer while finish just prints the 
values. I moved these to a separate compilation unit so the access isn't 
entirely optimized away.

Original issue reported on code.google.com by decoder...@googlemail.com on 16 Dec 2011 at 2:17

Attachments:

@GoogleCodeExporter
Copy link
Author

First of all, thanks a lot for a high quality reproducer!

I suspected we may have this problem when we observed 
http://llvm.org/bugs/show_bug.cgi?id=11376, but I was too lazy/busy to 
investigate further. 

This is a conflict of load widening and asan. 
We either need to disable load widening when asan is active, or disable such 
widening completely. 
I'll ask at the LLVM mailing list about their opinion.



% cat load_widening.c && echo ========= && clang  -O2  -c  load_widening.c 
-flto && llvm-dis load_widening.o && cat load_widening.o.ll 
void init(char *);
int foo() {
  char a[22];
  init(a);
  return a[16] + a[21];
}
=========
; ModuleID = 'load_widening.o'
target datalayout = 
"e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v6
4:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

define i32 @foo() nounwind uwtable {
entry:
  %a = alloca [22 x i8], align 16
  %arraydecay = getelementptr inbounds [22 x i8]* %a, i64 0, i64 0
  call void @init(i8* %arraydecay) nounwind
  %arrayidx = getelementptr inbounds [22 x i8]* %a, i64 0, i64 16
  %0 = bitcast i8* %arrayidx to i64*
  %1 = load i64* %0, align 16
  %2 = trunc i64 %1 to i32
  %sext = shl i32 %2, 24
  %conv = ashr exact i32 %sext, 24
  %3 = lshr i64 %1, 16
  %.tr = trunc i64 %3 to i32
  %sext3 = ashr i32 %.tr, 24
  %add = add nsw i32 %sext3, %conv
  ret i32 %add
}

declare void @init(i8*)


Even smaller repro: 

% cat main.c 
#include <string.h>

__attribute__((noinline))
void Init(unsigned char* buf, long bufsize) {
  memset(buf, 0xDA, bufsize);
}

int main(int argc, char **argv) {
  char data[22];
  Init(data, sizeof(data));
  return data[16] + data[21];
}
% clang -w -O2 -g    -faddress-sanitizer main.c && ./a.out  2>&1 | 
./asan_symbolize.py /
=================================================================
==22809== ERROR: AddressSanitizer stack-buffer-overflow on address 
0x7fff8b3661b0 at pc 0x401bad bp 0x7fff8b366170 sp 0x7fff8b366168
READ of size 8 at 0x7fff8b3661b0 thread T0
    #0 0x401bad in main main.c:11
    #1 0x7fdf3d594c4d in __libc_start_main libc-start.c:258
Address 0x7fff8b3661b0 is located at offset 48 in frame <main> of T0's stack:
  This frame has 1 object(s):
    [32, 54) 'data'
HINT: this may be a false positive if your program uses some custom stack 
unwind mechanism
      (longjmp and C++ exceptions *are* supported)
==22809== ABORTING
Stats: 0M malloced (0M for red zones) by 3 calls
Stats: 0M realloced by 0 calls
Stats: 0M freed by 3 calls
Stats: 0M really freed by 0 calls
Stats: 8M (2048 full pages) mmaped in 2 calls
  mmaps   by size class: 8:16383; 10:4095;
  mallocs by size class: 8:2; 10:1;
  frees   by size class: 8:2; 10:1;
  rfrees  by size class:
Stats: malloc large: 0 small slow: 2
Shadow byte and word:
  0x1ffff166cc36: 6
  0x1ffff166cc30: f1 f1 f1 f1 00 00 06 f4
More shadow bytes:
  0x1ffff166cc10: 00 00 00 00 00 00 00 00
  0x1ffff166cc18: 00 00 00 00 00 00 00 00
  0x1ffff166cc20: 00 00 00 00 00 00 00 00
  0x1ffff166cc28: 00 00 00 00 00 00 00 00
=>0x1ffff166cc30: f1 f1 f1 f1 00 00 06 f4
  0x1ffff166cc38: f3 f3 f3 f3 00 00 00 00
  0x1ffff166cc40: 00 00 00 00 00 00 00 00
  0x1ffff166cc48: 00 00 00 00 00 00 00 00
  0x1ffff166cc50: 00 00 00 00 00 00 00 00




Original comment by konstant...@gmail.com on 16 Dec 2011 at 6:12

  • Changed state: Accepted

@GoogleCodeExporter
Copy link
Author

Original comment by konstant...@gmail.com on 16 Dec 2011 at 6:12

@GoogleCodeExporter
Copy link
Author

Discussion: 
https://groups.google.com/group/llvm-dev/browse_thread/thread/24c297cff6aa1fbd/

Original comment by konstant...@gmail.com on 17 Dec 2011 at 12:06

@GoogleCodeExporter
Copy link
Author

i just tried firefox + asan from 
https://developer.mozilla.org/en/Building_Firefox_with_Address_Sanitizer.

Firefox is crashing on startup with following asan error log 


=================================================================
==18456== ERROR: AddressSanitizer stack-buffer-overflow on address 0xbfeaaac4 
at pc 0xb0e4d157 bp 0xbfea9398 sp 0xbfea9394
READ of size 4 at 0xbfeaaac4 thread T0
    #0 0xb0e4d157 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x135b3157)
    #1 0xb0e017b0 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x135677b0)
    #2 0xb0e00dd0 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x13566dd0)
    #3 0xb0e158ac (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x1357b8ac)
    #4 0xb0e4315e (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x135a915e)
    #5 0xb0e41fb3 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x135a7fb3)
    #6 0xb0e255d3 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x1358b5d3)
    #7 0xb0e1b2e7 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x135812e7)
    #8 0xb0e19ed7 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x1357fed7)
    #9 0xb08144ef (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x12f7a4ef)
    #10 0xa4d67ade (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x74cdade)
    #11 0xa4d27f39 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x748df39)
    #12 0xa49e1802 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x7147802)
    #13 0xa48ba6df (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x70206df)
    #14 0xb13ef3f5 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x13b553f5)
    #15 0xb13a4036 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x13b0a036)
    #16 0xb13b0b1e (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x13b16b1e)
    #17 0xb13afe51 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x13b15e51)
    #18 0xb1113a3b (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x13879a3b)
    #19 0xb10e0447 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x13846447)
    #20 0xb11c038c (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x1392638c)
    #21 0xb0a5c48e (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x131c248e)
    #22 0xb0d90b3c (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x134f6b3c)
    #23 0xb11fa813 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x13960813)
    #24 0xb11bfec7 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x13925ec7)
    #25 0xb111f6ba (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x138856ba)
    #26 0xb10e0447 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x13846447)
    #27 0xb11c038c (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x1392638c)
    #28 0xb0a5c48e (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x131c248e)
    #29 0xb11c3e82 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x13929e82)
    #30 0xb08b3ffa (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x13019ffa)
    #31 0xa8742bdb (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0xaea8bdb)
    #32 0xa86e32ee (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0xae492ee)
    #33 0xad66aca5 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0xfdd0ca5)
    #34 0xa30a98a1 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x580f8a1)
    #35 0xa30aaf68 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x5810f68)
    #36 0xa32f0e69 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x5a56e69)
    #37 0xa32d9b4a (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x5a3fb4a)
    #38 0xa32d6b27 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x5a3cb27)
    #39 0xa32de0f2 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x5a440f2)
    #40 0xa02c484d (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x2a2a84d)
    #41 0xa02ca5aa (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x2a305aa)
    #42 0xa02bb2a4 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x2a212a4)
    #43 0xa4c75cf1 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x73dbcf1)
    #44 0xa4c4e4eb (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x73b44eb)
    #45 0xab3e9343 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0xdb4f343)
    #46 0xab429f4a (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0xdb8ff4a)
    #47 0xab458ec0 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0xdbbeec0)
    #48 0x2e26284 (/usr/lib/libgtk-x11-2.0.so.0.2200.0+0x135284)
    #49 0xd5e412 (/usr/lib/libgobject-2.0.so.0.2600.1+0xc412)
    #50 0xd74b85 (/usr/lib/libgobject-2.0.so.0.2600.1+0x22b85)
    #51 0xd75e2b (/usr/lib/libgobject-2.0.so.0.2600.1+0x23e2b)
    #52 0xd76452 (/usr/lib/libgobject-2.0.so.0.2600.1+0x24452)
    #53 0x2f54b96 (/usr/lib/libgtk-x11-2.0.so.0.2200.0+0x263b96)
    #54 0x2e1e85d (/usr/lib/libgtk-x11-2.0.so.0.2200.0+0x12d85d)
    #55 0x2e1fed7 (/usr/lib/libgtk-x11-2.0.so.0.2200.0+0x12eed7)
    #56 0xe0f36a (/usr/lib/libgdk-x11-2.0.so.0.2200.0+0x5636a)
    #57 0xb34855 (/lib/libglib-2.0.so.0.2600.1+0x3d855)
    #58 0xb38668 (/lib/libglib-2.0.so.0.2600.1+0x41668)
    #59 0xb38848 (/lib/libglib-2.0.so.0.2600.1+0x41848)
    #60 0xab499356 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0xdbff356)
    #61 0xab5ed349 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0xdd53349)
    #62 0xab5efd59 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0xdd55d59)
    #63 0xab5f1984 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0xdd57984)
Address 0xbfeaaac4 is located at offset 324 in frame 
<_ZL7GCCycleP9JSContextP13JSCompartment18JSGCInvocationKind> of T0's stack:
  This frame has 11 object(s):
    [32, 36) 'cx.addr'
    [96, 100) 'comp.addr'
    [160, 164) 'gckind.addr'
    [224, 228) 'rt'
    [288, 292) 'gcsession'
    [352, 356) 'exn.slot'
    [416, 420) 'ehselector.slot'
    [480, 484) 'cleanup.dest.slot'
    [544, 556) 'sc'
    [608, 612) 'ref.tmp'
    [672, 680) 'c'
HINT: this may be a false positive if your program uses some custom stack 
unwind mechanism
      (longjmp and C++ exceptions *are* supported)
==18456== ABORTING
Stats: 1225M malloced (692M for red zones) by 531899 calls
Stats: 1038M realloced by 44032 calls
Stats: 1152M freed by 304584 calls
Stats: 985M really freed by 267103 calls
Stats: 1004M (257237 full pages) mmaped in 248 calls
  mmaps   by size class: 8:278511; 9:49146; 10:20475; 11:14329; 12:2048; 13:2560; 14:1536; 15:384; 16:448; 17:192; 18:128; 19:80; 20:132; 21:120; 22:70; 23:3; 
  mallocs by size class: 8:426805; 9:55405; 10:22657; 11:17262; 12:1946; 13:3584; 14:1576; 15:470; 16:584; 17:323; 18:291; 19:217; 20:378; 21:302; 22:94; 23:5; 
  frees   by size class: 8:213957; 9:48134; 10:20286; 11:15205; 12:1544; 13:1630; 14:1457; 15:423; 16:495; 17:214; 18:259; 19:211; 20:377; 21:300; 22:89; 23:3; 
  rfrees  by size class: 8:186881; 9:42620; 10:17703; 11:13348; 12:1507; 13:1540; 14:1443; 15:408; 16:473; 17:192; 18:227; 19:146; 20:263; 21:262; 22:87; 23:3; 
Stats: malloc large: 1610 small slow: 2471
Shadow byte and word:
  0x37fd5558: f2
  0x37fd5558: f2 f2 f2 f2
More shadow bytes:
  0x37fd5548: f2 f2 f2 f2
  0x37fd554c: 04 f4 f4 f4
  0x37fd5550: f2 f2 f2 f2
  0x37fd5554: 04 f4 f4 f4
=>0x37fd5558: f2 f2 f2 f2
  0x37fd555c: 04 f4 f4 f4
  0x37fd5560: f2 f2 f2 f2
  0x37fd5564: 04 f4 f4 f4
  0x37fd5568: f2 f2 f2 f2


is this because of the above issue ?

Original comment by sachinsh...@gmail.com on 4 Jan 2012 at 10:10

@GoogleCodeExporter
Copy link
Author

This seems to be a different issue (either a real bug in FF, or another bug in 
asan).
I suggest we discuss it in address-sanitizer@googlegroups.com or in a new bug. 
Let's start from symbolizing the output and looking at the FF source code. 

Original comment by kcc@chromium.org on 4 Jan 2012 at 10:20

@GoogleCodeExporter
Copy link
Author

I hope this is finally fixed by llvm r149925.

Original comment by konstant...@gmail.com on 6 Feb 2012 at 10:54

  • Changed state: Fixed

@GoogleCodeExporter
Copy link
Author

Adding Project:AddressSanitizer as part of GitHub migration.

Original comment by ramosian.glider@gmail.com on 30 Jul 2015 at 9:12

  • Added labels: ProjectAddressSanitizer

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant