ramosian-glider
commented
9 years ago 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
Originally reported on Google Code with ID 20
Reported by
decoder.ohon 2011-12-16 14:17:28