This is a serious security regression. If you are not able to fix this quickly, please revert the change that introduced it.

If this doesn't affect a release branch, or has not been properly classified for severity, please update the Security_Impact or Security_Severity labels, and remove the ReleaseBlock label. To disable this altogether, apply ReleaseBlock-NA.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

capn@, could you help triage this issue?  Thanks!

This is in LLVM code which we don't control. Plus it might be a false positive (UBSan doesn't know what function it points to). Going to suppress it in 
tools/ubsan/vptr_blacklist.txt

https://chromium-review.googlesource.com/c/559164/

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

commit 15ad36b93a803ce9b3da6f96ce971ac34e6f7f8c
Author: Nicolas Capens <capn@google.com>
Date: Thu Jul 06 18:28:06 2017

Suppress UBSan vptr issues in LLVM.

The Subzero JIT uses some LLVM code which is not UBSan vptr clean.

BUG= 737384 

Change-Id: I277e3ec65323e01ede5d213cf908ee76b9e63b79
Reviewed-on: https://chromium-review.googlesource.com/559164
Reviewed-by: Jialiu Lin <jialiul@chromium.org>
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Commit-Queue: Nicolas Capens <nicolascapens@google.com>
Cr-Commit-Position: refs/heads/master@{#484682}
[modify] https://crrev.com/15ad36b93a803ce9b3da6f96ce971ac34e6f7f8c/tools/ubsan/vptr_blacklist.txt

ClusterFuzz testcase 6676807968620544 is still reproducing on tip-of-tree build (trunk).

Please re-test your fix against this testcase and if the fix was incorrect or incomplete, please re-open the bug. Otherwise, ignore this notification and add ClusterFuzz-Wrong label.

Ah, there's a literal dash in the regex.

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

commit c2a38810b2a997665d422d2a48b023aa35c87b7f
Author: Nicolas Capens <capn@google.com>
Date: Fri Jul 14 20:56:27 2017

Fix UBSan blacklist regex containing dash.

BUG= 737384 

Change-Id: Ib74a5d2aed5cecc758c019e05672fff1f9e3337d
Reviewed-on: https://chromium-review.googlesource.com/572051
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Commit-Queue: Nicolas Capens <nicolascapens@google.com>
Cr-Commit-Position: refs/heads/master@{#486884}
[modify] https://crrev.com/c2a38810b2a997665d422d2a48b023aa35c87b7f/tools/ubsan/vptr_blacklist.txt

Tanin, this is another case where the ClusterFuzz report's minimized testcase is the same as the unminimized one, and the reproduce tool claims it hasn't been minimized yet.

Would that also explain why it doesn't consider it fixed yet, or is there another issue with the blacklisting regex?

capn@, thanks@, filed https://github.com/google/clusterfuzz-tools/issues/421 for tanin to take a look.

capn@, thanks for reporting this. To unblock you, here is the manually uploaded testcase (https://clusterfuzz.com/v2/testcase-detail/4585069732954112) that works with the reproduce tool.

Thanks, could you grant me access privileges to it?

Note that I don't strictly need to reproduce this, since we're just going to blacklist it. But the src filter rule doesn't seem to work correctly for some reason.

Detailed report: https://clusterfuzz.com/testcase?key=4585069732954112

Fuzzer: gpu_swiftshader_fuzzer
Job Type: libfuzzer_chrome_ubsan
Crash Type: Incorrect-function-pointer-type
Crash Address: 
Crash State:
  getManagedStaticMutex
  llvm::ManagedStaticBase::RegisterManagedStatic
  llvm::ManagedStatic<CommandLineParser>::operator*
  
Sanitizer: undefined (UBSAN)

Recommended Security Severity: Medium

Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=4585069732954112


See https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reproducing.md for more information.

Detailed report: https://clusterfuzz.com/testcase?key=4585069732954112

Fuzzer: gpu_swiftshader_fuzzer
Job Type: libfuzzer_chrome_ubsan
Crash Type: Incorrect-function-pointer-type
Crash Address: 
Crash State:
  getManagedStaticMutex
  llvm::ManagedStaticBase::RegisterManagedStatic
  llvm::ManagedStatic<CommandLineParser>::operator*
  
Sanitizer: undefined (UBSAN)

Recommended Security Severity: Medium

Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_ubsan&range=481528:482652

Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=4585069732954112


See https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reproducing.md for more information.

It looks like the UB is in libc++, and doesn't actually originate in LLVM. If I force LLVM_THREADING_USE_STD_CALL_ONCE to false, LLVM uses its own implementation of call_once(), and the issue is gone.

It looks to me like the function pointer type is actually correct. For reference, here's the stack trace when I repro it locally:

../../buildtools/third_party/libc++/trunk/src/mutex.cpp:235:13: runtime error: call to function void std::__1::__call_once_proxy<std::__1::tuple<void (&)()> >(void*) through pointer to incorrect function type 'void (*)(void *)'
buildtools/third_party/libc++/trunk/include/mutex:646: note: void std::__1::__call_once_proxy<std::__1::tuple<void (&)()> >(void*) defined here
    #0 0x7f4e44ae7fa8 in std::__1::__call_once(unsigned long volatile&, void*, void (*)(void*)) buildtools/third_party/libc++/trunk/src/mutex.cpp:235:13
    #1 0x7f4e3bb71f9c in call_once<void (&)()> buildtools/third_party/libc++/trunk/include/mutex:665:9
    #2 0x7f4e3bb71f9c in void llvm::call_once<void (&)()>(std::__1::once_flag&, void (&)()) third_party/swiftshader/third_party/llvm-subzero/include/llvm/Support/Threading.h:101
    #3 0x7f4e3bb71f2e in getManagedStaticMutex() third_party/swiftshader/third_party/llvm-subzero/lib/Support/ManagedStatic.cpp:34:3

@mmoroz, perhaps UBSan doesn't work properly for templated functions?

Another issue might be that __call_once() lives in libc++.so, and UBSan doesn't like function pointers from one module to be called in another (similar to  Issue swiftshader:31 ). @thomasanderson, have you encountered such issues elsewhere?

capn@, I don't know, but that sounds reasonable to me.

-fsanitize=function requires std::type_info objects for function types to have a unique pointer identity, otherwise it will report false positives. For that to happen, type_info symbols must appear in the DSO's dynamic symbol table.

https://cs.chromium.org/chromium/src/third_party/swiftshader/src/OpenGL/libGLESv2/BUILD.gn?l=100

It looks like libGLESv2.so is built with a version script that prevents type_info objects from appearing in the symbol table. You might try either not passing the version script for ubsan builds, or adding the type_info symbols (_ZTS* and _ZTI*) to the version script (* is supported as a wildcard in version scripts).

Thanks for the detailed explanation! I'll add the type_info symbols to the version script.

The following revision refers to this bug:
  https://swiftshader.googlesource.com/SwiftShader.git/+/14534b56bbd0d6cb9c6d01ab6f8bbfec4f3e93cc

commit 14534b56bbd0d6cb9c6d01ab6f8bbfec4f3e93cc
Author: Nicolas Capens <capn@google.com>
Date: Wed Jul 19 18:14:49 2017

Export type-info symbols.

Sanitizer tools require type information to catch undefined behavior and
other issues. This wasn't available accross libraries due to the version
script giving them hidden visibility, leading to false positives.

 Bug chromium:737384 

Change-Id: Iab3e25f4da3672f694e32c1c89278a3fe677d51a
Reviewed-on: https://swiftshader-review.googlesource.com/10728
Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Corentin Wallez <cwallez@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

[modify] https://crrev.com/14534b56bbd0d6cb9c6d01ab6f8bbfec4f3e93cc/src/OpenGL/libEGL/exports.map
[modify] https://crrev.com/14534b56bbd0d6cb9c6d01ab6f8bbfec4f3e93cc/src/OpenGL/libGLESv2/exports.map

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

commit 5de6c95c31bbdcdc5cfa478fa70d0b8ab803094f
Author: Nicolas Capens <capn@google.com>
Date: Wed Jul 19 21:21:28 2017

Roll SwiftShader 4d97f36..010a464

https://swiftshader.googlesource.com/SwiftShader.git/+log/4d97f36..010a464

BUG= 737384 

TEST=bots

CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel,linux_chromium_cfi_rel_ng;master.tryserver.chromium.android:android_optional_gpu_tests_rel

Change-Id: Ib297a22f55426153c816bf59fe6701a41ccef6a2
Reviewed-on: https://chromium-review.googlesource.com/578246
Reviewed-by: Alexis Hétu <sugoi@chromium.org>
Commit-Queue: Nicolas Capens <nicolascapens@google.com>
Cr-Commit-Position: refs/heads/master@{#487988}
[modify] https://crrev.com/5de6c95c31bbdcdc5cfa478fa70d0b8ab803094f/DEPS

ClusterFuzz has detected this issue as fixed in range 487975:488087.

Detailed report: https://clusterfuzz.com/testcase?key=6676807968620544

Fuzzer: libFuzzer_gpu_swiftshader_fuzzer
Job Type: libfuzzer_chrome_ubsan
Platform Id: linux

Crash Type: Incorrect-function-pointer-type
Crash Address: 
Crash State:
  getManagedStaticMutex
  llvm::ManagedStaticBase::RegisterManagedStatic
  llvm::ManagedStatic<CommandLineParser>::operator*
  
Sanitizer: undefined (UBSAN)

Recommended Security Severity: Medium

Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_ubsan&range=481528:482652
Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_ubsan&range=487975:488087

Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=6676807968620544


See https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reproducing.md for more information.

If you suspect that the result above is incorrect, try re-doing that job on the test case report page.

ClusterFuzz testcase 6676807968620544 is verified as fixed, so closing issue.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.

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

commit 2fc84faa525735f69bcf2ecdf1ca03f542d5fc73
Author: Nicolas Capens <capn@google.com>
Date: Thu Jul 20 18:39:09 2017

Remove ineffective UBSan suppression.

The issue was a general UBSan one, not a UBSan vptr issue. Also, we
didn't have to blacklist the false positive, but instead provided UBSan
wth the necessary type info.

BUG= 737384 

Change-Id: Ie6299e1edfc010ef976ab4fbefacba4d06e305b7
Reviewed-on: https://chromium-review.googlesource.com/579448
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Commit-Queue: Nicolas Capens <nicolascapens@google.com>
Cr-Commit-Position: refs/heads/master@{#488322}
[modify] https://crrev.com/2fc84faa525735f69bcf2ecdf1ca03f542d5fc73/tools/ubsan/vptr_blacklist.txt

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

 Issue 815185  has been merged into this issue.