Created attachment 463057 [details] Testcase Tested on linux intel 64 and ARMv7. Running the attached test case fails with the following message: #4 0x0045c58a in WTFCrashWithInfo () at WTF/Headers/wtf/Assertions.h:754 #5 0x0045d33e in WTF::StringImpl::characters16 (this=0x287fe14 <WTF::StringImpl::s_emptyAtomString>) at WTF/Headers/wtf/text/StringImpl.h:312 #6 0x0045dbea in WTF::String::characters16 (this=0xfffee9b4) at WTF/Headers/wtf/text/WTFString.h:106 #7 0x01251920 in JSC::ListFormatInput::ListFormatInput (this=0xfffee9a8, strings=...) at ../../Source/JavaScriptCore/runtime/IntlObjectInlines.h:318 #8 0x01250722 in JSC::IntlListFormat::formatToParts (this=0x2963aa8, globalObject=0x28cafd8, list=...) at ../../Source/JavaScriptCore/runtime/IntlListFormat.cpp:214 #9 0x018a7310 in JSC::intlListFormatPrototypeFuncFormatToParts (globalObject=0x28cafd8, callFrame=0xfffeeb68) at ../../Source/JavaScriptCore/runtime/IntlListFormatPrototype.cpp:101 #10 0xf3dff16a in ?? () Found by Igalia Fuzzing Campaign.
<rdar://problem/101291623>
Bisect shows the regression was introduced by commit 71265755b78a83c1cc5614e3fede36899e4e3a05. In String::convertTo16Bit(), the following line auto convertedString = String::createUninitialized(length, destination); calss: StringImpl::createUninitializedInternal(unsigned length, CharacterType*& data) { if (!length) { data = nullptr; return *empty(); } return createUninitializedInternalNonEmpty(length, data); } which returns *empty(), i.e., s_emptyAtomString. Because s_emptyAtomString is always initialized with s_hashFlag8BitBuffer, the ASSERT(!is8Bit()) fails in: const UChar* characters16() const { ASSERT(!is8Bit()); return m_data16; }
My mistake: we can work around this by adding an empty string check to ListFormatInput or by changing the assertion in characters16() so it only asserts when length is non-zero. Luckily the problem is only with the assertion. This pointer won’t be used for anything, so it doesn’t matter that it’s a pointer to zero 8-bit characters rather than to zero 16-bit characters.
This need not be treated as a security bug. There is no vulnerability here. The problem is with the assertion.
Pull request: https://github.com/WebKit/WebKit/pull/5537
Committed 255739@main (a7b9e4efad0c): <https://commits.webkit.org/255739@main> Reviewed commits have been landed. Closing PR #5537 and removing active labels.