Bug 174753
| Summary: | [Mac WK2] Potential null deref in WKView if WebPageProxy callbacks are invalidated in -[WKView dealloc] | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Wenson Hsieh <wenson_hsieh> |
| Component: | WebKit2 | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | ||
| Priority: | P2 | ||
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
Wenson Hsieh
This code in WKView:
- (void)dealloc
{
_data->_impl->page().setIconLoadingClient(nullptr);
_data->_impl = nullptr;
[_data release];
_data = nil;
[super dealloc];
}
...seems like it would be susceptible to the same problem described in https://bugs.webkit.org/show_bug.cgi?id=174751. If ~WebViewImpl is called after setting _data->_impl to nullptr and one of the pending callbacks that get invoked when invalidating the callback map calls on WKView to do some work involving the _data's _impl, we'll probably end up with a null deref.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Wenson Hsieh
Interestingly, this isn't normally an issue when closing the page because Safari actually tells the WebPageProxy to close() very early in the teardown process. That's not to say there shouldn't be a mechanism at the WebKit layer, though, to ensure that we don't crash if the WKView is released through some other codepath in Safari that doesn't explicitly close() the page before continuing with teardown.