1440627 - Various Crashes [@ NS_ABORT_OOM] in StructuredCloneHolder

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Christian Holler (:decoder)]

I've prototyped a new libfuzzer-based fuzzing target that uses dom::ipc::StructuredCloneData as its entry point to cover the StructuredCloneReader code that is browser-only. The target code has not landed on mozilla-central yet, if you need it to reproduce (in case stack + test attached do not suffice), please let me know.

The attached testcase crashes on mozilla-central revision 8a2584063e19:

Backtrace:

==28303==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7fd44939873c bp 0x7ffeb61c1330 sp 0x7ffeb61c1330 T0)
==28303==The signal is caused by a WRITE memory access.
==28303==Hint: address points to the zero page.
    #0 0x7fd44939873b in NS_ABORT_OOM(unsigned long) xpcom/base/nsDebugImpl.cpp:614:3
    #1 0x7fd4493684d7 in AllocFailed xpcom/string/nsTSubstring.h:831:5
    #2 0x7fd4493684d7 in SetCapacity xpcom/string/nsTSubstring.cpp:762
    #3 0x7fd4493684d7 in nsTSubstring<char16_t>::SetLength(unsigned int) xpcom/string/nsTSubstring.cpp:813
    #4 0x7fd44d11806e in mozilla::dom::(anonymous namespace)::ReadDirectoryInternal(JSStructuredCloneReader*, unsigned int, mozilla::dom::StructuredCloneHolder*) dom/base/StructuredCloneHolder.cpp:586:8
    #5 0x7fd44d0f0200 in ReadDirectory dom/base/StructuredCloneHolder.cpp:622:7
    #6 0x7fd44d0f0200 in mozilla::dom::StructuredCloneHolder::CustomReadHandler(JSContext*, JSStructuredCloneReader*, unsigned int, unsigned int) dom/base/StructuredCloneHolder.cpp:974
    #7 0x7fd45a8d116c in JSStructuredCloneReader::startRead(JS::MutableHandle<JS::Value>) js/src/vm/StructuredClone.cpp:2358:25
    #8 0x7fd45a8b9dba in JSStructuredCloneReader::read(JS::MutableHandle<JS::Value>) js/src/vm/StructuredClone.cpp:2596:10
    #9 0x7fd45a8b999c in ReadStructuredClone(JSContext*, JSStructuredCloneData&, JS::StructuredCloneScope, JS::MutableHandle<JS::Value>, JSStructuredCloneCallbacks const*, void*) js/src/vm/StructuredClone.cpp:632:14
    #10 0x7fd44d0ed139 in ReadFromBuffer dom/base/StructuredCloneHolder.cpp:344:8
    #11 0x7fd44d0ed139 in mozilla::dom::StructuredCloneHolder::ReadFromBuffer(nsISupports*, JSContext*, JSStructuredCloneData&, JS::MutableHandle<JS::Value>, mozilla::ErrorResult&) dom/base/StructuredCloneHolder.cpp:324
    #12 0x7fd4587b636b in FuzzingRunDomSC(unsigned char const*, unsigned long) dom/base/fuzztest/FuzzStructuredClone.cpp:53:10

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV xpcom/base/nsDebugImpl.cpp:614:3 in NS_ABORT_OOM(unsigned long)
==28303==ABORTING

According to :baku this might be a place where a fallible allocator should have been used instead. We also seem to have more of these with different stacks, I can post more in this bug so we can fix them all in batch maybe. Doing so would greatly help further fuzzing efforts on this target, therefore marking fuzzblocker.

This bug itself is not security-sensitive, but the fuzzing efforts around this target in general are, until we have found and fixed the most common bugs, so I would request to keep this concealed for the moment.

Comment 1

[Christian Holler (:decoder)]

Attachment: Testcase

Comment 2

[Christian Holler (:decoder)]

Attachment: bug1440627.patch

This patch fixes the crash in comment 0 and a few other, similar crashes I discovered afterwards, by using fallible with SetLength. I used NS_WARN_IF in all cases as suggested on IRC.

Comment 3

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/b8f0901cc921872fe903a90a1fcab96b3aca2c24
https://hg.mozilla.org/mozilla-central/rev/b8f0901cc921