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

[Jason Haslam]

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/43576d35/attachment.html>