Blink will externalize page allocated WebAssembly memory, thereby leaking all pages |
||||||||||
Issue descriptionChrome Version: Version 66.0.3348.0 (Developer Build) (64-bit) I discovered this looking at https://kripken.github.io/BananaBread/cube2/bb.html which runs fine the first time but will fail to allocate its WebAssembly heap on page refreshes. What happens is that we reserve some pages as the backing store for a WebAssembly.Memory object. This buffer is then passed to a Blob in blink. From the spec, this should create a copy of the data but instead blink calls Externalize and takes over ownership of that memory. Consequently, the pages never get unreserved. I have attached a minimal repro case. It allocates the memory correctly the first time but fails to allocate the second memory. Also, it will fail to allocate at all on page refresh.
,
Feb 27 2018
,
Feb 27 2018
,
Feb 27 2018
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
,
Feb 27 2018
Eric, can you take a look?
,
Feb 27 2018
Please add affected OSs.
,
Feb 27 2018
I imagine this affects all OSes, so I went ahead and marked all. I don't know that this should be a security issue. A memory leak should just lead to an out-of-memory error eventually, but this is something Chrome is designed to crash safely during. Stephan - I just built a tip-of-tree Chrome and haven't been able to repro the issue. At least, I'm not seeing any failures to allocate memory, even though they may still be leaking. Are there some other flags I need?
,
Feb 28 2018
I have updated chrome using gclient sync and then moved the v8 checkout manually forward to head. A normal checkout using gclient sync does not show this behavior. Not sure this has any security implications. You end up with a Blob object that holds the memory pages as its backing store. I asked clemensh@ and we decided to set it just in case. Chrome does not run out-of-memory, only wasm can no longer allocate pages for WebAssembly.Memory.
,
Mar 1 2018
What are your chromium and v8 hashes? I just tried with chromium at 2cbf4ed191dfd95cfb6adab309ae7c2e1ed2a67e and V8 at 0d2c85b70b44ffdfe3d66c947e754fe0a23de564 and didn't see the issue (I assume I should see an exception on the JavaScript console, right?)
,
Mar 1 2018
I probably have build an inconsistent version of chrome/v8 that made this problem arise. I was at chrome checkout 1b1925f5948620a2b5dd56b3bc8d36e221e14ee8 and v8 checkout 0d2c85b70b44ffdfe3d66c947e754fe0a23de564. I was not aware I need to move both forward %) And yes, it will show an exception.
,
Mar 1 2018
,
Mar 1 2018
I was able to repro the issue with the commits you gave. Looking through the recent log, I would guess https://chromium-review.googlesource.com/938968 is related. I've been making changes in this area recently, so maybe you just got unlucky and caught it in a broken state. I'm going to go ahead and close the bug since it doesn't repro on the latest revision. Feel free to reopen if you disagree.
,
Mar 27 2018
,
Jun 8 2018
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 |
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by hablich@chromium.org
, Feb 27 2018