Various members of the JSArray class hierarchy provide some version of createUninitialized/tryCreateUninitialized. These implementations return nullptr when various bad conditions exist, such as requests greater than available memory, etc. While we have nullptr checks in most places, there are a number of cases where these are not present. This makes it possible for arbitrary web content to crash WebKit through a nullptr dereference.
Created attachment 282964 [details] Patch
<rdar://problem/26075433>
Comment on attachment 282964 [details] Patch Why are we logging these failures instead of throwing a JS exception?
Comment on attachment 282964 [details] Patch Why didn't we see a log in the test output?
(In reply to comment #4) > Comment on attachment 282964 [details] > Patch > > Why didn't we see a log in the test output? It shows up in the stderr, so if the test fails you actually can see the logging output. I don't know how to get WTFLogAlways stuff into test output.
(In reply to comment #3) > Comment on attachment 282964 [details] > Patch > > Why are we logging these failures instead of throwing a JS exception? I don't think we throw JS exceptions from deep inside platform code (or at least a quick search didn't find anything helpful). I definitely CAN do so in CanvasRenderingContext2D::getImageData, which makes the test much clearer.
Created attachment 282969 [details] Patch
Comment on attachment 282969 [details] Patch Clearing flags on attachment: 282969 Committed r202887: <http://trac.webkit.org/changeset/202887>
All reviewed patches have been landed. Closing bug.