Automatically assigning owner based on suspected regression changelist https://chromium.googlesource.com/chromium/src/+/8c591c43c8d508412f44887b7d483003b7ce932b (Enable UBSan's pointer overflow check.).

If this is incorrect, please let us know why and apply the Test-Predator-Wrong-CLs label. If you aren't the correct owner for this issue, please unassign yourself as soon as possible so it can be re-triaged.

Didn't notice this was assigned to me. Removing myself so it can be triaged properly.

Unable to find actual suspect through code search and also observing no CL's under regression range, hence adding appropriate label and requesting someone from dev team to look in to this issue.

Thanks!

Assigning to third_party/flatbuffers OWNER

Wouter, could you take a look at this, please?

So, the funny thing is that UBSAN -fsanitize=pointer-overflow and the code is checking are actually doing the same thing. The verifier code here is a "flatbuffer sanitizer" that checks if all pointers it is producing are in range of the buffer. To do so, it constructs the pointer and checks it against the buffer start and end, which is what trips up UBSAN.

To fix this, I'd need to change the verifier to work in terms of offsets rather than pointers, which may be a good idea anyway. I'll have a look how involved that is.

I have a possible fix in the works.

Here is a possible fix:

https://github.com/google/flatbuffers/commit/8f1bebba058a8e8ab9fd08c116cf4434ec141fdd

This now uses offsets rather than pointers to do the bounds checks, so should hopefully appease UBSan. Ran it against the fuzzer locally, but probably could with more thorough testing.

Who is normally responsible for updating Chrome's copy of FlatBuffers from upstream?

I don't think we have a dedicated process. One of the owners of third_party/flatbuffers (engedy, battre, me) can update for flatbuffers on its next major release.

Note that "major releases" on FlatBuffers are there mostly for the purpose of people that like pinning on a version, they are not more or less likely to be better than master. So if you wish to fix this UBSan breakage, you could also consider updating earlier.

Gotcha, thanks aardappel. I can take ownership to update in that case, targeting M70.

Thank you, both!

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

commit 3ac88c101c872fb028f702f7c77b6cc4c6993407
Author: Charlie Harrison <csharrison@chromium.org>
Date: Thu Aug 16 20:06:01 2018

Update third_party/flatbuffers

Bug:  834710 
Change-Id: I447f01b540cb35dd941b045d4d2934d4990c2ae2
Reviewed-on: https://chromium-review.googlesource.com/1148460
Reviewed-by: Balazs Engedy <engedy@chromium.org>
Commit-Queue: Charlie Harrison <csharrison@chromium.org>
Cr-Commit-Position: refs/heads/master@{#583784}
[modify] https://crrev.com/3ac88c101c872fb028f702f7c77b6cc4c6993407/DEPS
[modify] https://crrev.com/3ac88c101c872fb028f702f7c77b6cc4c6993407/third_party/flatbuffers/BUILD.gn
[modify] https://crrev.com/3ac88c101c872fb028f702f7c77b6cc4c6993407/third_party/flatbuffers/README.chromium

ClusterFuzz has detected this issue as fixed in range 583782:583795.

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

Fuzzer: libFuzzer_flatbuffers_verifier_fuzzer
Job Type: libfuzzer_chrome_ubsan
Platform Id: linux

Crash Type: Pointer-overflow
Crash Address: 
Crash State:
  flatbuffers::Table::GetVTable
  flatbuffers::Table::VerifyTableStart
  MyGame::Example::Stat::Verify
  
Sanitizer: undefined (UBSAN)

Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_ubsan&range=551565:551569
Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_ubsan&range=583782:583795

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

See https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reference.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 6425614295498752 is verified as fixed, so closing issue as verified.

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