[cfe-dev] Address sanitizer failures in readdir and statfs on Mac

[Alexander Potapenko]

There are intercepors for various uninstrumented libc functions invisible
to the tool otherwise. They are used to report addressability bugs in the
data passed into libc.
Some interceptors can be disabled using ASAN_OPTIONS (not sure about
readdir(), need to look that up), though you can't disable them just for
third party libraries.
Keep in mind that although you sometimes can make ASan ignore a heap
corruption this doesn't fix the bug, and something may break later due to
this wild write.
On Feb 23, 2014 3:17 AM, "Jason Haslam" <jason.haslam at gmail.com> wrote:

> The code in question is in Qt. I think that it must have been a real bug
> in the code since I can no longer reproduce after trying the most recent
> version of Qt. I also haven’t been able reproduce the error in a minimal
> sample. I’m pretty sure that I started seeing the issue when I switched
> from 10.8 to 10.9, but that doesn’t mean that it’s not a bug in the client
> code.
>
> On a slightly different topic, I’m a little confused about why I even get
> errors in Qt the first place since it was built without address sanitizer
> instrumentation. I didn't expect to see any errors there. Is there any way
> that I can ignore errors in third party libraries like this?
>
> In any case, I apologize for the false alarm. Thanks for the help!
>
> Jason
>
>
> On Feb 21, 2014, at 10:53 PM, Kostya Serebryany <kcc at google.com> wrote:
>
> +glider
> Are you certain that this is not a real bug in your code?
> Could you provide a minimal test case?
> Does test/asan/TestCases/Linux/interception_readdir_r_test.cc work on your
> machine?
> (or, simply, does 'make check-asan' work?)
>
> This might be something in 10.9 that has changed since 10.8.
> Afaict, we are still not testing asan on 10.9 (glider?)
> Could you please send a preprocessed source of a test calling readdir_r so
> that I can see the definition of struct dirent?
>
> Looking at your report I see:
> WRITE of size 48830 at 0x11617988 thread T0
> 0x11617988 is located 0 bytes to the right of 520-byte region
> [0x11617780,0x11617988)
>
> So, somewhere in your heap you've allocated 520 bytes of memory for
> dirent.
> Then our readdir_r interceptor does this:
>   int res = REAL(readdir_r)(dirp, entry, result);
>   if (!res) {
>     COMMON_INTERCEPTOR_WRITE_RANGE(ctx, result, sizeof(*result));
>
>     if (*result)
>       COMMON_INTERCEPTOR_WRITE_RANGE(ctx, *result, (*result)->d_reclen);
>   }
>
> Since we see "WRITE of size 48830", this is likely the second
> "COMMON_INTERCEPTOR_WRITE_RANGE"
> with d_reclen=48830. That's quite unexpected I think.
>
> --kcc
>
>
>
>
> On Sat, Feb 22, 2014 at 2:39 AM, Jason Haslam <jason.haslam at gmail.com>wrote:
>
>> I see address sanitizer failures with TOT clang in readdir_r on Mac OS
>> 10.9 like the following:
>>
>> =================================================================
>> *==61104==ERROR: AddressSanitizer: heap-buffer-overflow on address
>> 0x11617988 at pc 0x7fff36a bp 0xbffc2698 sp 0xbffc2684*
>> *WRITE of size 48830 at 0x11617988 thread T0*
>>     #0 0x7fff369 in wrap_readdir_r
>> (/Users/jason/llvm/build/release/lib/clang/3.5/lib/darwin/libclang_rt.asan_osx_dynamic.dylib+0x12369)
>> ...
>> *0x11617988 is located 0 bytes to the right of 520-byte region
>> [0x11617780,0x11617988)*
>> *allocated by thread T0 here:*
>>     #0 0x800ab1f in wrap_malloc
>> (/Users/jason/llvm/build/release/lib/clang/3.5/lib/darwin/libclang_rt.asan_osx_dynamic.dylib+0x1db1f)
>> ...
>> SUMMARY: AddressSanitizer: heap-buffer-overflow ??:0 wrap_readdir_r
>> ...
>> ==61104==ABORTING
>>
>> I get similar failures in statfs. Does anybody else see this? I got
>> around these issues with the attached patch. Is there a better way to fix
>> this without disabling these interceptors?
>>
>> Jason
>>
>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140222/bbd8df4e/attachment.html>