Author: pbos
Project: chromium-webrtc
Changelist: https://chromium.googlesource.com/external/webrtc/trunk/webrtc.git/+/8f5983ab0154050b5b36dec57e4a827fac4b228d
Time: Sat Nov 05 10:10:22 2016
The CL last changed line 19 of file h264_bitstream_parser_fuzzer.cc, which is stack frame 1.

Kari can you take a look? I believe this is returning the last QP when it's not parsed. I believe GetLastSliceQp should've returned false and not read undefined values here.

Ubsan can be enabled by:

'--args=use_libfuzzer=true is_ubsan_security=true' to gn gen.

.. or that these values need to be range checked.

Seems a little unnecessary to add range checks for this case, that should never occur in legitimate cases, and if it does, really has no consequences. However, it seems weird to me that this could even happen, so is probably indicative of another problem. I will investigate this.

We shouldn't rely on legitimate/illegitimate cases since this is to be controlled by network traffic (that's why we added a fuzzer for it). It having no consequences or not depends on compiler optimizations, since it's undefined behavior (and we try to keep the webrtc code ubsan clean).

If you can then please fix it instead of adding suppressions, this allows us to further test the code with ubsan. :)

Removing EditIssue view restrictions from ClusterFuzz filed bugs. If you believe that this issue should still be restricted, please reapply the label.

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

The following revision refers to this bug:
  https://chromium.googlesource.com/external/webrtc.git/+/b336392562dfd2febd66fcc2bdd531ea27c721bf

commit b336392562dfd2febd66fcc2bdd531ea27c721bf
Author: kthelgason <kthelgason@webrtc.org>
Date: Fri Dec 02 09:29:48 2016

Sanity check parsed QP values from H264 bitstream

BUG= chromium:663610 

Review-Url: https://codereview.webrtc.org/2532973002
Cr-Commit-Position: refs/heads/master@{#15377}

[modify] https://crrev.com/b336392562dfd2febd66fcc2bdd531ea27c721bf/webrtc/common_video/h264/h264_bitstream_parser.cc
[modify] https://crrev.com/b336392562dfd2febd66fcc2bdd531ea27c721bf/webrtc/common_video/h264/pps_parser.cc
[modify] https://crrev.com/b336392562dfd2febd66fcc2bdd531ea27c721bf/webrtc/common_video/h264/pps_parser_unittest.cc

This should be fixed now. Is it safe to close this bug or is something else needed to reenable the tests on clusterfuzz?

Should get auto-reported as fixed when this is rolled into Chromium and ClusterFuzz picks it up. It's never disabled on ClusterFuzz. :)

ClusterFuzz has detected this issue as fixed in range 436239:436257.

Detailed report: https://cluster-fuzz.appspot.com/testcase?key=5760244061044736

Fuzzer: libfuzzer_h264_bitstream_parser_fuzzer
Job Type: libfuzzer_chrome_ubsan
Platform Id: linux

Crash Type: Integer-overflow
Crash Address: 
Crash State:
  webrtc::H264BitstreamParser::GetLastSliceQp
  webrtc::FuzzOneInput
  _start
  
Regressed: https://cluster-fuzz.appspot.com/revisions?job=libfuzzer_chrome_ubsan&range=430572:430611
Fixed: https://cluster-fuzz.appspot.com/revisions?job=libfuzzer_chrome_ubsan&range=436239:436257

Minimized Testcase (0.23 Kb): https://cluster-fuzz.appspot.com/download/AMIfv94acXXKpHv_RY0k77M8bxMqEqMtqydMke_yLWJi9g5lYsbYi0OPVixifPHT1SLqtU1f8cvzJuXhclfSPny9YAxH4iSoOhEREFfkOXvTX8CcAJQUm9xFS6lDUT4TOYobCn1i4dgqMobAyNeZRgpeVkHz6w4Etw?testcase_id=5760244061044736

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.