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

Already on GitHub? Sign in to your account

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

Closed
ramosian-glider opened this Issue Aug 31, 2015 · 7 comments

Comments

Projects
None yet
2 participants
Member

ramosian-glider commented Aug 31, 2015

Originally reported on Google Code with ID 20

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.

Reported by decoder.oh on 2011-12-16 14:17:28


- _Attachment: [testAsanOptimizeSize.tgz](https://storage.googleapis.com/google-code-attachments/address-sanitizer/issue-20/comment-0/testAsanOptimizeSize.tgz)_
Member

ramosian-glider commented Aug 31, 2015

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-v64: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




Reported by konstantin.s.serebryany on 2011-12-16 18:12:30

  • Status changed: Accepted
Member

ramosian-glider commented Aug 31, 2015

Reported by konstantin.s.serebryany on 2011-12-16 18:12:43

Member

ramosian-glider commented Aug 31, 2015

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

Reported by konstantin.s.serebryany on 2011-12-17 00:06:46

Member

ramosian-glider commented Aug 31, 2015

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 ?

Reported by sachinshinde11 on 2012-01-04 22:10:09

Member

ramosian-glider commented Aug 31, 2015

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. 

Reported by kcc@chromium.org on 2012-01-04 22:20:40

Member

ramosian-glider commented Aug 31, 2015

I hope this is finally fixed by llvm r149925.

Reported by konstantin.s.serebryany on 2012-02-06 22:54:46

  • Status changed: Fixed
Member

ramosian-glider commented Aug 31, 2015

Adding Project:AddressSanitizer as part of GitHub migration.

Reported by ramosian.glider on 2015-07-30 09:12:58

  • Labels added: ProjectAddressSanitizer
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment