search for: redzones

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

Hi I am using SanitizerCoverage feature supported by clang to get the basicblock coverage. my tested binaries are spec cpu2006. I compiled the binary with the option COPTIMIZE = -O0 -fsanitize=address -fsanitize-coverage=bb -flto -fno-strict-aliasing -std=gnu89 -gdwarf-3 After the compiling process is end. I run the 400.perlbench. with the command ASAN_OPTIONS=coverage=1 ./perlbench.

Hi If so, is it able to disable this check. All I need is just to get the BB coverage information Regards Muhui Alexander Potapenko <glider at google.com>于2018年9月5日 周三下午6:57写道： > This is a known problem in SPECCPU2006, see > https://github.com/google/sanitizers/wiki/AddressSanitizerFoundBugs > On Wed, Sep 5, 2018 at 7:36 AM Muhui Jiang via llvm-dev > <llvm-dev at

Hi Alex Thanks for your email. But it seems not work. I removed the -fsanitize=address flag. The global buffer overflow message doesn't show. However, no *.sancov file is created after I run perlbench. Thus, I could not get the BB coverage. Do you have any ideas? Many Thanks Regards Muhui Alexander Potapenko <glider at google.com> 于2018年9月5日周三 下午7:14写道： > Hi Muhui, > > If

https://bugzilla.samba.org/show_bug.cgi?id=13112 Bug ID: 13112 Summary: receive_xattr heap overread with non null terminated name and xattr filter Product: rsync Version: 3.1.3 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 Component: core

https://bugzilla.netfilter.org/show_bug.cgi?id=1432 Bug ID: 1432 Summary: ebtables ebtables-2.0.11 buffer overflow on getting kernel data ( ebtables compiled with address sanitizer) Product: netfilter/iptables Version: unspecified Hardware: x86_64 OS: Debian GNU/Linux Status:

Author: arutz Repository: /hg/zfs-crypto/gate Revision: d6168689a27a22f7ca097c0dfd29141db33d147f Log message: 5097578 cdrw dumps a core due to redzone violation Files: update: usr/src/cmd/cdrw/device.c update: usr/src/cmd/cdrw/write_audio.c

https://bugzilla.samba.org/show_bug.cgi?id=13105 Bug ID: 13105 Summary: 1byte heap overflow in sanitize_path Product: rsync Version: 3.1.3 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 Component: core Assignee: wayned at samba.org Reporter:

...p being put into the .cstring > section, for which the following rules apply: > - the strings can't contain zeroes in their bodies > - the link editor places only one copy of each literal into the > output file's section > > ASan usually instruments the globals by adding redzones to the end of > them and creating a structure that contains the size of a global with > and without the redzone. > For the aforementioned strings the linker will delete the redzones, > but leave that structure untouched, which will lead to corrupt shadow > memory at run time. > &g...

https://bugzilla.samba.org/show_bug.cgi?id=13113 Bug ID: 13113 Summary: receive_xattr heap overflow when prepending RSYNC_PREFIX Product: rsync Version: 3.1.3 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 Component: core Assignee: wayned

This simple patch makes asan compile for mips (tested on mips32r2el). The following test code: int main() { char *x = (char*)malloc(10 * sizeof(char*)); free(x); return x[5]; } leads to the following output at runtime: ================================================================= ==267== ERROR: AddressSanitizer: heap-use-after-free on address 0x77900fd5 at pc 0x409e1c bp 0x7fb781d8 sp

I'm struggling to explain an ASAN report I'm now getting that I didn't get previously on the same code. In fact the report only happens with -O2 and not when I remove the -O flags which makes it hard to debug and makes me suspect it's dependent on exactly which instructions the code generation decides to access the bytes involved. Afaict the C code shouldn't be accessing the

Kostya, all, I'm trying to build my project by clang 3.8rc1 with enabled asan (clang itself is address sanitized) and it fails on several files from my project (ISPC, https://github.com/ispc/ispc). I've reproduced this on MacOS and Linux. Please let me know if you need any other info. How to reproduce: 1) Build address sanitized clang 3.8rc1: cd /path-to-working-dir svn co

Hi, In order to find out-of-bound accesses to global objects with AddressSanitizer ( http://code.google.com/p/address-sanitizer/wiki/AddressSanitizer) I need to create redzones to the left and to the right of every global variable. I tried the following: Before: @Extern = global [10 x i8] zeroinitializer, align 1 After: %0 = type { [32 x i8], [10 x i8], [54 x i8] } @Extern_asan_redzone = global %0 zeroinitializer, align 1 @0 = global [10 x i8] zeroinitializer, al...

...san/TestCases/Linux/nohugepage_test.cc - Miscellaneous: compiler-rt/test/asan/TestCases/Linux/allocator_oom_test.cc This test assumes amount of available memory. compiler-rt/test/asan/TestCases/stack-buffer-overflow-with-position.cc This fails because we don't have enough redzones to disambiguate overflow of one stack object vs underflow of the next stack object. - Here is the full list of revisions. I'll add review requests shortly. [asan] Add CMake hook to override default shadow scale https://reviews.llvm.org/D39469 [asan] Fix size/alignment is...

...string >> section, for which the following rules apply: >> - the strings can't contain zeroes in their bodies >> - the link editor places only one copy of each literal into the >> output file's section >> >> ASan usually instruments the globals by adding redzones to the end of >> them and creating a structure that contains the size of a global with >> and without the redzone. >> For the aforementioned strings the linker will delete the redzones, >> but leave that structure untouched, which will lead to corrupt shadow >> memory...

...Memory do exactly that -- and pay large performance and memory costs. Addressability checker (like asan) requires little shadow memory, but needs large redzone around allocated objects. Tools that track uninitialized/tainted data need bit-per-bit shadow in worst case, but don't need redzones. So, if we merge the tools together we multiply the memory overheads. The instrumentation costs in a combined tool are mostly added to each other (e.g. asan needs to poison redzones and msan needs to propagate shadow through arithmetic insns). Thanks, --kcc -------------- next part --...

On Tue, Jan 12, 2016 at 12:54 PM, Linus Torvalds <torvalds at linux-foundation.org> wrote: > On Tue, Jan 12, 2016 at 12:30 PM, Andy Lutomirski <luto at kernel.org> wrote: >> >> I recall reading somewhere that lock addl $0, 32(%rsp) or so (maybe even 64) >> was better because it avoided stomping on very-likely-to-be-hot write >> buffers. > > I suspect it

On Tue, Jan 12, 2016 at 12:54 PM, Linus Torvalds <torvalds at linux-foundation.org> wrote: > On Tue, Jan 12, 2016 at 12:30 PM, Andy Lutomirski <luto at kernel.org> wrote: >> >> I recall reading somewhere that lock addl $0, 32(%rsp) or so (maybe even 64) >> was better because it avoided stomping on very-likely-to-be-hot write >> buffers. > > I suspect it

> On Mar 24, 2016, at 1:55 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> One more, just for fun: Inter-procedural stack allocation. That is of calls bar, bar needs 4 bytes of stack space. Instead of bar allocating 4 bytes, it adds an attribute to itself, then foo allocates 4 bytes of space at the bottom of the stack for bar to use. > > This is something that