rtti is only needed for ubsan vptr, so probably only enable for is_ubsan_security.

Hm, looks like a managed to resolve rtti issue, but cannot get things work anyway:

$ UBSAN_OPTIONS=halt_on_error=1:print_stacktrace=1 ~/Projects/new/chromium/src/out/Release/zlib_uncompress_fuzzer ../zlib_uncompress_fuzzer/
Segmentation fault (core dumped)

(gdb) r
Starting program: /usr/local/google/home/mmoroz/Projects/new/chromium/src/out/Release/zlib_uncompress_fuzzer ../zlib_uncompress_fuzzer/
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/grte/v4/lib64/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x000000000041ffad in HandleDynamicTypeCacheMiss(__ubsan::DynamicTypeCacheMissData*, unsigned long, unsigned long, __ubsan::ReportOptions) ()
(gdb) bt
#0  0x000000000041ffad in HandleDynamicTypeCacheMiss(__ubsan::DynamicTypeCacheMissData*, unsigned long, unsigned long, __ubsan::ReportOptions) ()
#1  0x000000000041ff82 in __ubsan_handle_dynamic_type_cache_miss ()
#2  0x00007ffff7d3b1dd in __dynamic_cast ()
    at ../../buildtools/third_party/libc++abi/trunk/src/private_typeinfo.cpp:648
#3  0x0000000000420ec6 in __ubsan::checkDynamicType(void*, void*, unsigned long) ()
#4  0x000000000041ffb2 in HandleDynamicTypeCacheMiss(__ubsan::DynamicTypeCacheMissData*, unsigned long, unsigned long, __ubsan::ReportOptions) ()
#5  0x000000000041ff82 in __ubsan_handle_dynamic_type_cache_miss ()
#6  0x00007ffff7d3b1dd in __dynamic_cast ()
    at ../../buildtools/third_party/libc++abi/trunk/src/private_typeinfo.cpp:648
#7  0x0000000000420ec6 in __ubsan::checkDynamicType(void*, void*, unsigned long) ()
#8  0x000000000041ffb2 in HandleDynamicTypeCacheMiss(__ubsan::DynamicTypeCacheMissData*, unsigned long, unsigned long, __ubsan::ReportOptions) ()
#9  0x000000000041ff82 in __ubsan_handle_dynamic_type_cache_miss ()
#10 0x00007ffff7d3b1dd in __dynamic_cast ()
    at ../../buildtools/third_party/libc++abi/trunk/src/private_typeinfo.cpp:648
#11 0x0000000000420ec6 in __ubsan::checkDynamicType(void*, void*, unsigned long) ()
<...>



What am I doing wrong?

Looks like a stack overflow due to infinite recursion -- ubsan calls itself. 
Can you provide exact repro steps? 
(Ideally outside of chrome build system on a smaller test, if that's easy; but in chrome build system is ok too)

Unfortunately I don't know how to reproduce this outside of Chrome. I did the following changes: https://codereview.chromium.org/2018973002/

And then trying to build any fuzzer (zlib_uncompress_fuzzer is a small enough and compiles quickly) with the following gn args:

is_debug = false
use_goma = true
use_libfuzzer = true
is_ubsan_security = true
enable_nacl = false
proprietary_codecs = true


Then I just run the fuzzer with existing corpus or empty corpus, it doesn't matter.

I guess that there are some missing or non-compatible compilation flags: https://paste.googleplex.com/5020962495922176

Alexey doesn't work on this any more, :( un-CC-ing him. 

Gack! Are we instrumenting third_party/libc++abi/trunk/src/private_typeinfo.cpp
with ubsan vptr? Weee, this is not going to work :) 

You either need to convince gn to not pass -fsanitize=vptr when building 
third_party/libc++abi/*
or you should try to put 
__attribute__((no_sanitize("vptr"))) on __dynamic_cast

Attribute is preferable but then you will have to wait until it gets upstream and then back you chrome. 

Thanks for your insight! Trying to get it work locally.
Not succeeded with adding an attribute, but adding private_typeinfo.cpp into blacklist works.

Uploaded changes for a review: https://codereview.chromium.org/2018973002/

Btw, what are other interesting UBSan flags from a security point of view?
I consider the following flags:
- bounds
- function
- object-size
- vla-bound

What can you recommend to enable also?

>> - bounds
I would not expect this to find anything on top of asan,
but theoretically such cases are possible (...maybe)

>> - function
This would be interesting to try, I don't have any personal experience with this flag. 

- object-size
- vla-bound
>> No experience here. Probably worth a try too. 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/16e7bcd3b68643a269fcec6163f18b16d97234bc

commit 16e7bcd3b68643a269fcec6163f18b16d97234bc
Author: mmoroz <mmoroz@chromium.org>
Date: Wed Jun 01 09:27:30 2016

[libfuzzer] Add 'vptr' flag to builds with UndefinedBehaviourSanitizer.

security_blacklist.txt is a merge of blacklist.txt and vptr_blacklist.txt.

BUG= 609786 

Review-Url: https://codereview.chromium.org/2018973002
Cr-Commit-Position: refs/heads/master@{#397090}

[modify] https://crrev.com/16e7bcd3b68643a269fcec6163f18b16d97234bc/build/common.gypi
[modify] https://crrev.com/16e7bcd3b68643a269fcec6163f18b16d97234bc/build/config/compiler/BUILD.gn
[modify] https://crrev.com/16e7bcd3b68643a269fcec6163f18b16d97234bc/build/config/sanitizers/BUILD.gn
[add] https://crrev.com/16e7bcd3b68643a269fcec6163f18b16d97234bc/tools/ubsan/security_blacklist.txt
[modify] https://crrev.com/16e7bcd3b68643a269fcec6163f18b16d97234bc/tools/ubsan/vptr_blacklist.txt

Hm, I'm a bit concerned that we don't have any vptr reports from 90+ fuzzers.

I've tested the following code locally: https://paste.googleplex.com/5347576236736512
with 'is_ubsan_security = true'.

When the code uses `dynamic_cast` crash isn't too informative: https://paste.googleplex.com/5955692334678016

For `reinterpret_cast` or C-style cast it crashes correctly: https://paste.googleplex.com/5005066016653312

It seems likely that we ignore those crashes (with `dynamic_cast`) because it doesn't contain any crash markers.

Can you artifically introduce a startup one in your local build for one of the fuzzers and attach what stack you get here.

ah, i should have read c#14 properly. Dynamic_cast already does the cast check . Check the issue with static_cast.

Checked for static_cast:


class A;
class B : A;
class C : A;
static_cast of (object B ) to object C:


runtime error: downcast of address 0x000002f45680 which does not point to an object of type 'C'
0x000002f45680: note: object is of type 'B'


Full output: https://paste.googleplex.com/5629875847168000

Well, everything looks fine. Abhishek told me that 'dynamic_cast' isn't used in production. All other casts should be detected and reported correctly.