Date: Sun, 28 Feb 2016 23:16:59 +0100 From: Jilles Tjoelker <jilles@stack.nl> To: Dimitry Andric <dim@FreeBSD.org> Cc: Howard Su <howard0su@gmail.com>, current@freebsd.org Subject: Re: buffer overflow warning in /bin/sh Message-ID: <20160228221659.GA30583@stack.nl> In-Reply-To: <0353BD46-1397-4DAC-9115-6D2355E7F42D@FreeBSD.org> References: <CAAvnz_owSKcJ71LJa2F4MnnWKjV251CH-mBsVMFcS=riN=bK_Q@mail.gmail.com> <0353BD46-1397-4DAC-9115-6D2355E7F42D@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Feb 26, 2016 at 06:21:20PM +0100, Dimitry Andric wrote: > On 26 Feb 2016, at 04:21, Howard Su <howard0su@gmail.com> wrote: > > I got the error when compiling GENERIC kernel with address sanitizer > > /bin/sh: > > --- vers.c --- > > MAKE=make sh /usr/home/howardsu/freebsd/sys/conf/newvers.sh > > GENERIC================================================================= > > ==4132==ERROR: AddressSanitizer: stack-buffer-overflow on address > > 0x7fffffffc9c0 at pc 0x00000045fdc7 bp 0x7fffffffc930 sp 0x7fffffffc0f0 > > WRITE of size 312 at 0x7fffffffc9c0 thread T0 > > #0 0x45fdc6 (/bin/sh+0x45fdc6) > > #1 0x801431767 (/lib/libc.so.7+0x7c767) > > #2 0x42ff5e (/bin/sh+0x42ff5e) > > #3 0x4b6b00 (/bin/sh+0x4b6b00) > > #4 0x49686e (/bin/sh+0x49686e) > > #5 0x495572 (/bin/sh+0x495572) > > #6 0x48c3f9 (/bin/sh+0x48c3f9) > > #7 0x489920 (/bin/sh+0x489920) > > #8 0x4acde8 (/bin/sh+0x4acde8) > > #9 0x4aca4d (/bin/sh+0x4aca4d) > > #10 0x40fb0e (/bin/sh+0x40fb0e) > > #11 0x80071afff (<unknown module>) > > Address 0x7fffffffc9c0 is located in stack of thread > > T0==4132==AddressSanitizer CHECK failed: > > /usr/home/howardsu/freebsd/lib/libclang_rt/asan/../../../contrib/compiler-rt/lib/asan/asan_thread.cc:246 > > "((ptr[0] == kCurrentStackFrameMagic)) != (0)" (0x0, 0x0) > > #0 0x422b9d (/bin/sh+0x422b9d) > > #1 0x41de09 (/bin/sh+0x41de09) > > #2 0x41f301 (/bin/sh+0x41f301) > > #3 0x4728be (/bin/sh+0x4728be) > > #4 0x474589 (/bin/sh+0x474589) > > #5 0x47502a (/bin/sh+0x47502a) > > #6 0x45fdef (/bin/sh+0x45fdef) > > #7 0x801431767 (/lib/libc.so.7+0x7c767) > > #8 0x42ff5e (/bin/sh+0x42ff5e) > > #9 0x4b6b00 (/bin/sh+0x4b6b00) > > #10 0x49686e (/bin/sh+0x49686e) > > #11 0x495572 (/bin/sh+0x495572) > > #12 0x48c3f9 (/bin/sh+0x48c3f9) > > #13 0x489920 (/bin/sh+0x489920) > > #14 0x4acde8 (/bin/sh+0x4acde8) > > #15 0x4aca4d (/bin/sh+0x4aca4d) > > #16 0x40fb0e (/bin/sh+0x40fb0e) > > #17 0x80071afff (<unknown module>) > > *** [vers.c] Error code 1 > > I am using latest -Current and add the following flags to /etc/make.conf. > > # CFLAGS+= -g -fsanitize=address -fno-omit-frame-pointer > > I rebuild /bin/sh as a first step. with the /bin/sh I got the above error. > > I would like to understand how to get symbols. The following command > > doesn't work at all. > > addr2line -e /bin/sh 0x422b9d > > Any idea? > Please recompile and reinstall world, using WITH_CLANG_EXTRAS=y in > /etc/src.conf. This will install the /usr/bin/llvm-symbolizer command, > which is needed by AddressSanitizer to resolve symbols. I tried this a while ago and asan reported an error when libc cleared a piece of stack memory (va_list, fully in bounds) using asan-interposed memset(). Note that glibc never calls memset() internally in such a way that it can be interposed. > On my system with the projects/clang380-import branch installed, I get > the following AdressSanitizer report. It does not look completely > similar to your case, though: > $ sh sys/conf/newvers.sh > ================================================================= > ==9912==ERROR: AddressSanitizer: stack-buffer-overflow on address 0xbfbfe380 at pc 0x08121f12 bp 0xbfbfe354 sp 0xbfbfe34c > WRITE of size 4 at 0xbfbfe380 thread T0 > #0 0x8121f11 in readtoken1 /share/dim/src/freebsd/base/projects/clang380-import/bin/sh/parser.c:1419:22 > #1 0x812597d in xxreadtoken /share/dim/src/freebsd/base/projects/clang380-import/bin/sh/parser.c:930:11 > #2 0x811c90f in readtoken /share/dim/src/freebsd/base/projects/clang380-import/bin/sh/parser.c:827:6 > #3 0x812341c in simplecmd /share/dim/src/freebsd/base/projects/clang380-import/bin/sh/parser.c:647:7 > #4 0x812341c in command /share/dim/src/freebsd/base/projects/clang380-import/bin/sh/parser.c:592 > #5 0x8122e19 in pipeline /share/dim/src/freebsd/base/projects/clang380-import/bin/sh/parser.c:376:7 > #6 0x811cc57 in andor /share/dim/src/freebsd/base/projects/clang380-import/bin/sh/parser.c:347:6 > #7 0x811cc57 in list /share/dim/src/freebsd/base/projects/clang380-import/bin/sh/parser.c:278 > #8 0x8126501 in parsebackq /share/dim/src/freebsd/base/projects/clang380-import/bin/sh/parser.c:1182:6 > #9 0x811f36c in readtoken1 /share/dim/src/freebsd/base/projects/clang380-import/bin/sh/parser.c:1556:11 > #10 0x812597d in xxreadtoken /share/dim/src/freebsd/base/projects/clang380-import/bin/sh/parser.c:930:11 > #11 0x811c90f in readtoken /share/dim/src/freebsd/base/projects/clang380-import/bin/sh/parser.c:827:6 > #12 0x811c7c9 in parsecmd /share/dim/src/freebsd/base/projects/clang380-import/bin/sh/parser.c:224:6 > #13 0x811046f in cmdloop /share/dim/src/freebsd/base/projects/clang380-import/bin/sh/main.c:217:7 > #14 0x811015e in main /share/dim/src/freebsd/base/projects/clang380-import/bin/sh/main.c:178:3 > #15 0x80557c9 in _start1 (/bin/sh+0x80557c9) > Address 0xbfbfe380 is located in stack of thread T0 at offset 32 in frame > #0 0x811e8ff in readtoken1 /share/dim/src/freebsd/base/projects/clang380-import/bin/sh/parser.c:1400 > This frame has 3 object(s): > [16, 20) 'bqlist' > [32, 128) 'state_static' <== Memory access at offset 32 is inside this variable > [160, 170) 'buf' > HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext > (longjmp and C++ exceptions *are* supported) > SUMMARY: AddressSanitizer: stack-buffer-overflow /share/dim/src/freebsd/base/projects/clang380-import/bin/sh/parser.c:1419:22 in readtoken1 > Shadow bytes around the buggy address: > 0x57f7fc20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x57f7fc30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x57f7fc40: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 00 00 > 0x57f7fc50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x57f7fc60: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 04 f2 > =>0x57f7fc70:[f3]f3 f3 f3 f3 f3 00 00 00 00 00 00 f2 f2 f2 f2 > 0x57f7fc80: 00 02 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 > 0x57f7fc90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x57f7fca0: 00 00 00 00 00 00 00 00 f1 f1 04 f2 04 f2 04 f2 > 0x57f7fcb0: 04 f2 04 f3 00 00 00 00 00 00 00 00 00 00 00 00 > 0x57f7fcc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > Shadow byte legend (one shadow byte represents 8 application bytes): > Addressable: 00 > Partially addressable: 01 02 03 04 05 06 07 > Heap left redzone: fa > Heap right redzone: fb > Freed heap region: fd > Stack left redzone: f1 > Stack mid redzone: f2 > Stack right redzone: f3 > Stack partial redzone: f4 > Stack after return: f5 > Stack use after scope: f8 > Global redzone: f9 > Global init order: f6 > Poisoned by user: f7 > Container overflow: fc > Array cookie: ac > Intra object redzone: bb > ASan internal: fe > Left alloca redzone: ca > Right alloca redzone: cb > ==9912==ABORTING > This may be a false positive though. The reported store, which is near the top of the function, is clearly within bounds. -- Jilles Tjoelker
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160228221659.GA30583>