1490423 - [libFuzzer] Null-deref crash [@ mozilla::gfx::RecordedFill::PlayEvent | mozilla::gfx::InlineTranslator::TranslateRecording]

Status: RESOLVED INCOMPLETE

(Core :: Graphics: WebRender, defect, P2)

Description

[Jesse Schwartzentruber (:truber)]

Attachment: testcase.cpp

The attached call to wr_moz2d_render_cb causes a null dereference in m-c rev 423bdf7a802b0d302244492b423609187de39f56.


==3354==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f09516ed9f4 bp 0x7ffd5e05bcf0 sp 0x7ffd5e05bba0 T0)
==3354==The signal is caused by a READ memory access.
==3354==Hint: address points to the zero page.
    #0 0x7f09516ed9f3 in mozilla::gfx::RecordedFill::PlayEvent(mozilla::gfx::Translator*) const /home/truber/src/m/u/gfx/2d/RecordedEventImpl.h:1964:39
    #1 0x7f09516e3769 in operator() /home/truber/src/m/u/gfx/2d/InlineTranslator.cpp:84:54
    #2 0x7f09516e3769 in bool mozilla::gfx::RecordedEvent::DoWithEvent<mozilla::gfx::InlineTranslator::TranslateRecording(char*, unsigned long)::MemReader, mozilla::gfx::InlineTranslator::TranslateRecording(char*, unsigned long)::$_0>(mozilla::gfx::InlineTranslator::TranslateRecording(char*, unsigned long)::MemReader&, mozilla::gfx::RecordedEvent::EventType, mozilla::gfx::InlineTranslator::TranslateRecording(char*, unsigned long)::$_0) /home/truber/src/m/u/gfx/2d/RecordedEventImpl.h:3493
    #3 0x7f09516d4be8 in mozilla::gfx::InlineTranslator::TranslateRecording(char*, unsigned long) /home/truber/src/m/u/gfx/2d/InlineTranslator.cpp:77:20
    #4 0x7f095259522c in mozilla::wr::Moz2DRenderCallback(mozilla::Range<unsigned char const>, mozilla::gfx::IntSizeTyped<mozilla::gfx::UnknownUnits>, mozilla::gfx::SurfaceFormat, unsigned short const*, mozilla::wr::TypedPoint2D<unsigned short, mozilla::wr::Tiles> const*, mozilla::wr::TypedRect<unsigned int, mozilla::wr::DevicePixel> const*, mozilla::Range<unsigned char>) /home/truber/src/m/u/gfx/webrender_bindings/Moz2DImageRenderer.cpp:433:22
    #5 0x7f0952590cec in wr_moz2d_render_cb /home/truber/src/m/u/gfx/webrender_bindings/Moz2DImageRenderer.cpp:473:10
    #6 0x7f095eb0462c in testMoz2DRenderCallback(unsigned char const*, unsigned long) /home/truber/src/m/u/gfx/tests/fuzzing/moz2d/TestMoz2D.cpp:91:3
    #7 0x55ac528d9864 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /home/truber/src/m/u/tools/fuzzing/libfuzzer/FuzzerLoop.cpp:517:13
    #8 0x55ac528b032f in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /home/truber/src/m/u/tools/fuzzing/libfuzzer/FuzzerDriver.cpp:280:6
    #9 0x55ac528bbe61 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /home/truber/src/m/u/tools/fuzzing/libfuzzer/FuzzerDriver.cpp:703:9
    #10 0x7f095d58d2c1 in mozilla::FuzzerRunner::Run(int*, char***) /home/truber/src/m/u/tools/fuzzing/interface/harness/FuzzerRunner.cpp:60:10
    #11 0x7f095d49f275 in XREMain::XRE_mainStartup(bool*) /home/truber/src/m/u/toolkit/xre/nsAppRunner.cpp:3997:35
    #12 0x7f095d4b34d3 in XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&) /home/truber/src/m/u/toolkit/xre/nsAppRunner.cpp:4956:12
    #13 0x7f095d4b504e in XRE_main(int, char**, mozilla::BootstrapConfig const&) /home/truber/src/m/u/toolkit/xre/nsAppRunner.cpp:5063:21
    #14 0x55ac5281d6fc in do_main /home/truber/src/m/u/browser/app/nsBrowserApp.cpp:233:22
    #15 0x55ac5281d6fc in main /home/truber/src/m/u/browser/app/nsBrowserApp.cpp:315
    #16 0x7f097500282f in __libc_start_main /build/glibc-Cl5G7W/glibc-2.23/csu/../csu/libc-start.c:291
    #17 0x55ac5271d038 in _start (/home/truber/src/m/u/obj/ff-asan-release/dist/bin/firefox+0x37038)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /home/truber/src/m/u/gfx/2d/RecordedEventImpl.h:1964:39 in mozilla::gfx::RecordedFill::PlayEvent(mozilla::gfx::Translator*) const
==3354==ABORTING

Comment 1

[Jeff Muizelaar [:jrmuizel]]

So we don't have any protection against doing null dereferences in recording playback. This kind of crash should be fine and not a security problem. Is there any reason we can't just ignore this kind of thing? Does it make fuzzing harder?

Comment 2

[Jesse Schwartzentruber (:truber)]

Fair enough. It does make fuzzing much slower with tools like libFuzzer, since it is an in-process fuzzer.

Comment 3

[Jeff Muizelaar [:jrmuizel]]

Is it worse than MOZ_RELEASE_ASSERT?

Comment 4

[Jesse Schwartzentruber (:truber)]

No, it's the same problem. I currently have all the MOZ_RELEASE_ASSERTS #ifdef'd to return when running libFuzzer.

Comment 5

[Jeff Muizelaar [:jrmuizel]]

This is not exploitable. I don't think we should block on it.

Comment 6

[Andrei Purice]

Hey Jesse,
Can you still reproduce this issue or can it be closed?

Comment 7

[Andrei Purice]

Marking this as Resolved > Incomplete due to the lack of info.
If anyone is able to reproduce this issue re-open it or file a new bug.