Bug 149864
Summary: | Possible null pointer dereference in WebSocket::connect | ||
---|---|---|---|
Product: | WebKit | Reporter: | Michael Catanzaro <mcatanzaro> |
Component: | WebCore Misc. | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED CONFIGURATION CHANGED | ||
Severity: | Normal | CC: | aestes, annevk, ap, bfulgham, cdumez, jiewen_tan, mcatanzaro, wilander |
Priority: | P2 | ||
Version: | Other | ||
Hardware: | All | ||
OS: | All |
Michael Catanzaro
I noticed this issue due to the fix for bug #149311.
Later down in WebSocket::connect() there is a call to document.frame()->loader().mixedContentChecker(). I don't see why that doesn't crash now, since it occurs if (is<Document>(*scriptExecutionContext()), the same condition as the null dereference of frame up above, which was problematic in bug #149311. That was "safe" when I added it because document.frame() was assumed to be nonnull up above, but clearly that was wrong and is now no longer the case.
I guess if it's not crashing (is it returning early on an error path?), then it might not be a problem, but it looks dangerous in light of this change... do we need to add a check to make sure frame is not null there? If so, do we need to rethink how to gain access to the mixed content checker, or is the content in a detached frame not going to be loaded? We need to be careful not to accidentally allow loading insecure content here.
Attachments | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
Anne van Kesteren
It looks like this has been refactored and frame is null-checked now.