I unfortunately don't have access to a Galaxy S6 to test this, but this looks like an interesting bug.

Ken, any ideas here? I'm wondering if there's any additional validation we could do.

I tested this on a Google Pixel and can't reproduce the capture of corrupted VRAM.

I'd like to understand better whether the browser thinks the WebGL context's been lost at the time toDataURL is called. If it is, we should return a blank image rather than attempting to actually perform the readback.

The problem appears to be related to the injection of this long-running no-op loop in the fragment shader:

  for(
      int GLF_live3i = 0;
      GLF_live3i < 12244;
      GLF_live3i ++
  )
  {
  }

The first time I tried this test case on my MacBook Pro it caused a GPU hang and reset, but it wasn't reproducible afterward. I didn't have the server running (would be better if it was written in Python 2.x for macOS compatibility) but did see a flash of what looked like garbage VRAM.

Reducing to low security severity and P2 because evidence is that this affects only specific devices. We'd need one to diagnose this in more detail. Prudhvi, do we have an S6 in house that we can use for testing?

I am fairly certain the WebGL context is not lost on the Samsung Galaxy S6. There is no popup and no refreshing occurred. 

The included fragment shader indeed probably only works for ARM Mali GPUs as in the Samsung Galaxy S6. I think some Sony Xperia phones may also have Mali GPUs, if that helps. 

A different fragment shader might be able to cause a similar issue on other GPUs. Sometimes adding a "discard" or early "return" statement (possibly conditional on a uniform) is enough to cause garbage. But in this case we indeed believe it is the long running loop. 

Changing the loop bound can also have an effect. E.g. a lower loop bound might not hang certain GPUs. Note that the loop bound could be provided in a uniform parameter, so a straightforward loop bound static analysis is unlikely to be enough to detect this. 

I attach an updated zip where `server.py` works with Python 2 and 3. 

Deleted: webgl-bug2.zip 3.5 MB

webgl-bug2.zip 3.5 MB Download

Thanks. No garbage observed with your server on macOS 10.11.6 with Chrome 57.0.2956.0 (Official Build) canary (64-bit).

Ligi, Prudhvi, do we have a Samsung Galaxy S6 on which I could run a test? Ligi, assigning to you so this doesn't get dropped.

Got the S6 (thanks Prudhvi), and confirm that garbage is observed when running the test case.

Upgrading this back to Security_Severity-Medium and P1. I think the information leak is significant.

Filed internal bug b/33757419 about this, in the bug category for the Mali GPU. I'll also contact a couple of colleagues at ARM and Samsung who may be able to help triage this.

My best guess is that the Mali GPU is aborting a long-running command buffer without signaling that the context is lost via the GL_KHR_robustness extension, although Chrome is allocating its contexts with that reset strategy turned on (visible in about:gpu). Chrome needs that reset notification in order to lose the WebGL context and prevent information leakage such as this. There is already code in place for this purpose.

I'm not sure what we can do about this yet. Marking ExternalDependency to indicate that we don't have any solutions yet from the Chrome side, and need feedback from ARM.

Could I check the status of this?

1. Has the issue been reported to ARM? To whom? Has there been a response?
2. Has the issue been reported to Samsung? To whom? Has there been a response?
3. Can we get cc'ed in these conversations? And/or is there an id or reference number (from ARM/Samsung) we can use if we want to refer to these bug reports?
4. Do ARM and Samsung know that the shader was generated by fuzzing (using GLFuzz)?

Thanks

I've asked those questions on our internal bug.  What I can share now is that Samsung is definitely aware of this; hopefully we can answer the rest of your questions in the near future.

kbr@, can you circle back once we have more details?

Yes, I'll update this bug when either ARM or Samsung gets back to us.

Could I check on the status of this? 

Asked ARM/Samsung for a status update on the internal bug b/33757419 .

I can no longer reproduce this after updating my Samsung S6 (Europe). 
Android 7.0; SM-G920F Build/NRD90M

The rendered image is transparent and, sometimes, the context is lost (I see "Rats! WebGL hit a snag"). 

Thanks. That's the expected behavior; KHR_robustness is supposed to lose the context in this situation. I've asked for confirmation on b/33757419 but most likely we'll have to close this as WontFix (no longer reproducible). Also, we never got a bug ID from ARM or Samsung.

Thanks. We have confirmation from Samsung that they saw the bug report and confirmation from ARM that they saw the report and fixed the bug thanks to our report. 

That's great news.

Closed the internal bug as Fixed, but closing this one as WontFix since we didn't make any code changes to Chromium in response, and since it's no longer reproducible after a rollout of Samsung's newest driver.

Is it possible to manually check if we are still eligible for a reward? My understanding of the program is that we might still be eligible. But I assume we are automatically marked as ineligible when the status is changed to WontFix. 

"Bugs may be eligible even if they are part of the base operating system and can manifest through Chrome."

"...bugs may be eligible even if they are caused by components of the operating system or standard libraries. We're interested in rewarding any information that enables us to better protect our users. In the event of bugs in an external component, we are happy to take care of responsibly notifying other affected parties."

Oops. Sorry, didn't mean to break your eligibility for a reward, especially since the capture of content occurred through the browser.

Marking as ExternalDependency again and resetting the reward label.

Thanks so much. Hopefully it is not necessary for the bug to be marked as Fixed/Verified to trigger the next stage of the reward process. If it is necessary, perhaps this bug can be manually flagged for review, as we believe it is fixed (and the fix is deployed) but this may not be clear. 

Thanks!  Going to mark this as Fixed since the security issue is indeed fixed (this is in line with how we track this in similar situations, like security bugs in Flash).  The VRP panel will look at this soon.  Thanks!

This bug requires manual review: M61 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), ketakid@(ChromeOS), govind@(Desktop)

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

Per c#24 there is nothing to merge here, but correct me if I'm wrong...

That's right! I think the aim is to mark this as fixed, merged, etc. (whatever is appropriate), despite the fact that there are no changes to Chromium, so that the rewards panel will review this. I am not sure if some additional labels are needed. 

*** Boilerplate reminders! ***
Please do NOT publicly disclose details until a fix has been released to all our users. Early public disclosure may cancel the provisional reward. Also, please be considerate about disclosure when the bug affects a core library that may be used by other products. Please do NOT share this information with third parties who are not directly involved in fixing the bug. Doing so may cancel the provisional reward. Please be honest if you have already disclosed anything publicly or to third parties. Lastly, we understand that some of you are not interested in money. We offer the option to donate your reward to an eligible charity. If you prefer this option, let us know and we will also match your donation - subject to our discretion. Any rewards that are unclaimed after 12 months will be donated to a charity of our choosing.
*********************************

Congratulations! The Chrome VRP panel decided to award $2,000 for this report. A member of our finance team will be in touch to arrange payment.

Thanks! We received the reward! Since the fix was actually released some time ago (I think probably around April 2017), is it possible to make this Chromium issue/report public so we can refer to it?

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