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

Nicolas, could you help to find an owner for this?

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

commit 2d4b7be6248d1f8ae9898f74174fa4393ae36435
Author: Nicolas Capens <capn@google.com>
Date: Tue Jun 27 17:04:17 2017

Don't crash when using a buffer with no data.

It's undefined behavior when an application attempts to use a buffer
for which no data has been allocated yet, but this is trivial for us to
check for and produce a non-fatal error.

 Bug chromium:736639 

Change-Id: I795c22363ada1b5e325d1fb5061a9e7673609879
Reviewed-on: https://swiftshader-review.googlesource.com/10309
Tested-by: Nicolas Capens <capn@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>

[modify] https://crrev.com/2d4b7be6248d1f8ae9898f74174fa4393ae36435/src/OpenGL/libGLESv2/VertexDataManager.cpp

Note that the above patch does not catch cases where buffer data was allocated, but isn't large enough.

Antoine, is it the command buffer's responsibility to check for this? SwiftShader mostly adheres to the garbage-in-garbage-out principle. We attempted to implement GL_KHR_robust_buffer_access_behavior a while ago, but it ever got finished (https://swiftshader-review.googlesource.com/4431).

Yes, it is the responsibility of the command buffer to catch this case.

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

commit cbb68c26a16ba1215d8bae41459cb5cf5e8ffda9
Author: capn <capn@chromium.org>
Date: Wed Jun 28 16:55:41 2017

Roll SwiftShader 9282c6d..81aa97b

https://swiftshader.googlesource.com/SwiftShader.git/+log/9282c6d..81aa97b

BUG= 736639 
BUG= 732691 

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: Id4c9f8ec2a01c1f5dc3d9bfeb7478763d60482ea
Review-Url: https://codereview.chromium.org/2957173003
Cr-Commit-Position: refs/heads/master@{#483029}

[modify] https://crrev.com/cbb68c26a16ba1215d8bae41459cb5cf5e8ffda9/DEPS

It looks like we only bounds check the enabled attributes that are used by the program. I don't think the spec says whether unused attributes can be dereferenced or not, but I think we should play it safe and either fail the draw (like for used attributes) or disable the unused attributes.

ClusterFuzz has detected this issue as fixed in range 483013:483057.

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

Fuzzer: inferno_layout_test_fuzzer
Job Type: linux_asan_chrome_v8_arm
Platform Id: linux

Crash Type: Unknown-crash READ {*}
Crash Address: 0x30e23400
Crash State:
  es2::VertexDataManager::writeAttributeData
  es2::VertexDataManager::prepareVertexData
  es2::Context::applyVertexBuffer
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=linux_asan_chrome_v8_arm&range=478007:478131
Fixed: https://clusterfuzz.com/revisions?job=linux_asan_chrome_v8_arm&range=483013:483057

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


See https://dev.chromium.org/Home/chromium-security/bugs/reproducing-clusterfuzz-bugs 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 6008632818008064 is verified as fixed, so closing issue.

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

Forked into  crbug.com/738228  to fix the general issue.

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

commit 0b77eb162eec2286c5b7e9a84c2f25362e39b7ad
Author: Antoine Labour <piman@chromium.org>
Date: Sat Jul 08 04:00:44 2017

Fix potential OOB reads in matrix attributes

This fixes how we handle matrix attributes to properly take into account
all the locations that they use instead of just the first one.

Bug:  736639 ,  738228 
Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: I0ca7d9b8a962d7de13016f5c04d5ab1d7348f514
Reviewed-on: https://chromium-review.googlesource.com/553746
Reviewed-by: Antoine Labour <piman@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Commit-Queue: Antoine Labour <piman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#485138}
[modify] https://crrev.com/0b77eb162eec2286c5b7e9a84c2f25362e39b7ad/gpu/BUILD.gn
[modify] https://crrev.com/0b77eb162eec2286c5b7e9a84c2f25362e39b7ad/gpu/command_buffer/service/program_manager.cc
[modify] https://crrev.com/0b77eb162eec2286c5b7e9a84c2f25362e39b7ad/gpu/command_buffer/service/program_manager.h
[modify] https://crrev.com/0b77eb162eec2286c5b7e9a84c2f25362e39b7ad/gpu/command_buffer/service/program_manager_unittest.cc
[add] https://crrev.com/0b77eb162eec2286c5b7e9a84c2f25362e39b7ad/gpu/command_buffer/tests/gl_oob_attrib_unittest.cc

 Issue 736631  has been merged into this issue.

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