Re: buffer overflow warning in /bin/sh

From: Jilles Tjoelker <jilles_at_stack.nl>
Date: Sun, 28 Feb 2016 23:16:59 +0100
On Fri, Feb 26, 2016 at 06:21:20PM +0100, Dimitry Andric wrote:
> On 26 Feb 2016, at 04:21, Howard Su <howard0su_at_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
Received on Sun Feb 28 2016 - 21:17:03 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:03 UTC