From 0b1d21cd8e9f7a97ab66c15ee2d013cc4b5a33b1 Mon Sep 17 00:00:00 2001 From: Andrew McCreight Date: Thu, 23 Jan 2020 21:03:44 +0000 Subject: [PATCH] Bug 1608760 - Make ClonedErrorHolder::ToErrorValue() deal with a null filename. r=bzbarsky If you serialize and then deserialize a JSErrorReport with a null filename field, then we end up passing a null filename to JS::CreateError, which ends up crashing. Perhaps CreateError should be robust against a null filename, but the fact that whatever latent null filename issue wasn't causing crashes until this serialization was added suggests it might be reasonable to deal with it inside ClonedErrorHolder. This patch causes a null string to instead become an empty string. We could do this on the sending side, but by dealing with it on the receiving side we get the bonus of keeping a malicious sender from crashing us. Differential Revision: https://phabricator.services.mozilla.com/D60587 --HG-- extra : moz-landing-system : lando --- dom/ipc/ClonedErrorHolder.cpp | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/dom/ipc/ClonedErrorHolder.cpp b/dom/ipc/ClonedErrorHolder.cpp index 42d5d1cb7561..6a1eb7521335 100644 --- a/dom/ipc/ClonedErrorHolder.cpp +++ b/dom/ipc/ClonedErrorHolder.cpp @@ -279,6 +279,15 @@ bool ClonedErrorHolder::ToErrorValue(JSContext* aCx, if (mType == Type::JSError) { JS::Rooted filename(aCx); JS::Rooted message(aCx); + + // For some unknown reason, we can end up with a void string in mFilename, + // which will cause filename to be null, which causes JS::CreateError() to + // crash. Make this code against robust against this by treating void + // strings as the empty string. + if (mFilename.IsVoid()) { + mFilename.Assign(EmptyCString()); + } + if (!ToJSString(aCx, mFilename, &filename) || !ToJSString(aCx, mMessage, &message)) { return false;