149864 2015-10-06 17:41:48 -0700 Possible null pointer dereference in WebSocket::connect 2023-05-12 08:00:46 -0700 1 1 1 Unclassified WebKit WebCore Misc. Other All All RESOLVED CONFIGURATION CHANGED P2 Normal --- 1 mcatanzaro webkit-unassigned aestes annevk ap bfulgham cdumez jiewen_tan mcatanzaro wilander oldest_to_newest 1131174 0 mcatanzaro 2015-10-06 17:41:48 -0700 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. 1954974 1 annevk 2023-05-12 08:00:46 -0700 It looks like this has been refactored and frame is null-checked now.