1820983 - AddressSanitizer: global-buffer-overflow [@ mozilla::a11y::Accessible::GetLevel] with READ of size 4

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Christian Holler (:decoder)]

In experimental IPC fuzzing, we found the following crash on mozilla-central revision f14ed3bab724+ (fuzzing-asan-nyx-opt build):

=================================================================
==1960==ERROR: AddressSanitizer: global-buffer-overflow on address 0x7ffff0934c78 at pc 0x7fffe58db17a bp 0x7ffffffd92c0 sp 0x7ffffffd92b8
READ of size 4 at 0x7ffff0934c78 thread T0
    #0 0x7fffe58db179 in mozilla::a11y::Accessible::GetLevel(bool) const accessible/basetypes/Accessible.cpp:0:0
    #1 0x7fffe58193b0 in mozilla::UniquePtr<nsTArray<nsCOMPtr<nsIContent> >, mozilla::DefaultDelete<nsTArray<nsCOMPtr<nsIContent> > > >::get_deleter() objdir-ff-aflpp/dist/include/mozilla/UniquePtr.h:288:0
    #2 0x7fffe5b80dfc in non-virtual thunk to mozilla::a11y::XULComboboxAccessible::ActionNameAt(unsigned char, nsTSubstring<char16_t>&) accessible/xul/XULComboboxAccessible.cpp:0:0
    #3 0x7fffe5b80231 in mozilla::a11y::XULComboboxAccessible::Value(nsTString<char16_t>&) const accessible/xul/XULComboboxAccessible.cpp:75:0
    #4 0x7fffe5b7fecf in mozilla::a11y::XULComboboxAccessible::Description(nsTString<char16_t>&) const accessible/xul/XULComboboxAccessible.cpp:67:26
    #5 0x7fffe5b7fd45 in mozilla::a11y::XULComboboxAccessible::Description(nsTString<char16_t>&) const accessible/xul/XULComboboxAccessible.cpp:61:0
    #6 0x7fffe5b7fbb1 in nsCOMPtr<nsIDOMXULMenuListElement>::operator->() const objdir-ff-aflpp/dist/include/nsCOMPtr.h:869:0
    #7 0x7fffe5b7f9f6 in mozilla::a11y::XULComboboxAccessible::NativeState() const accessible/xul/XULComboboxAccessible.cpp:45:10
    #8 0x7fffe5b7f7f4 in mozilla::a11y::XULComboboxAccessible::NativeRole() const accessible/xul/XULComboboxAccessible.cpp:30:50
    #9 0x7fffe5b7f668 in ?? ??:0
    #10 0x7fffe5b7f427 in mozilla::a11y::XULAlertAccessible::XULAlertAccessible(nsIContent*, mozilla::a11y::DocAccessible*) accessible/xul/XULAlertAccessible.cpp:0:17
    #11 0x7fffe5b60b65 in mozilla::a11y::xpcAccessibleHyperText::GetCharacterCount(int*) accessible/xpcom/xpcAccessibleHyperText.cpp:45:20
    #12 0x7fffe5b608f1 in non-virtual thunk to mozilla::a11y::xpcAccessibleHyperText::AddRef() accessible/xpcom/xpcAccessibleHyperText.cpp:0:0
    #13 0x7fffe59dc5d2 in mozilla::a11y::RemoteAccessibleBase<mozilla::a11y::RemoteAccessible>::RemotePrevSibling() const objdir-ff-aflpp/dist/include/mozilla/a11y/RemoteAccessibleBase.h:64:19
    #14 0x7fffe59db377 in nsTHashtable<nsIntegralHashKey<unsigned long, 0> >::EnsureRemoved(unsigned long const&) objdir-ff-aflpp/dist/include/nsTHashtable.h:356:0
    #15 0x7fffe59dca20 in RefPtr<nsIAccessibleEvent>::RefPtr<xpcAccHideEvent, void>(RefPtr<xpcAccHideEvent>&&) objdir-ff-aflpp/dist/include/mozilla/RefPtr.h:145:0
    #16 0x7fffe5b1e147 in mozilla::a11y::PDocAccessibleParent::OnMessageReceived(IPC::Message const&) objdir-ff-aflpp/ipc/ipdl/PDocAccessibleParent.cpp:9738:13
    #17 0x7fffda9eff7a in mozilla::dom::PContentParent::OnMessageReceived(IPC::Message const&) objdir-ff-aflpp/ipc/ipdl/PContentParent.cpp:6872:27
    [...]

This is another crash I found while fuzzing PDocAccessibleParent specifically, but I can't make any sense of the trace yet.

Fwiw, PDocAccessibleParent.cpp:9738:13 in my local build is this code:

https://searchfox.org/mozilla-central/source/__GENERATED__/__linux64__/ipc/ipdl/PDocAccessibleParent.cpp#9738

            AUTO_PROFILER_LABEL("PDocAccessible::Msg_SelectionEvent", OTHER);

            IPC::MessageReader reader__{
                    msg__,
                    this};
            uint64_t aID{};              <-----HERE
            uint64_t aWidgetID{};
            uint32_t aType{};

Reproducing this is difficult because it depends on the Mochitest we have been running in the VM. We could try to run the mochitest outside the VM with the standard reproduction procedure for Nyx bugs at least to get an idea of the message trace. However, if anyone already can see what's wrong here, that'd be easier.

Comment 1

[Christian Holler (:decoder)]

Attachment: Detailed Crash Information

Comment 2

[Christian Holler (:decoder)]

Fwiw, there is a chance that this is a memory corruption of some sort that isn't reported earlier for whatever reasons. If e.g. bug 1820389 manages to write out of bounds in a valid way such that ASan isn't tripped, all sorts of things could happen.

Comment 3

[Christian Holler (:decoder)]

Fwiw, I believe I reproduced this once more in fuzzing and I was able to confirm that the patches for bug 1860001 fix this one too. I am not sure if it is strictly the same issue but it was an out-of-bounds in the aria role map and the patch in bug 1860001 adds bounds checks in multiple methods. Calling it FIXED because the initial testcase here was for SelectionEvent and did not involve Windows code.

Comment 4

[Daniel Veditz [:dveditz]]

Bulk-unhiding security bugs fixed in Firefox 119-121 (Fall 2023). Use "moo-doctrine-subsidy" to filter