1956156 - UndefinedBehaviorSanitizer: SEGV /gecko-dev/obj-fuzzbuild/dist/include/mozilla/Assertions.h:267:3 in MOZ_CrashSequence(void*, long)

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine: JIT, defect, P3)

Description

[Jingyi Chen]

Attachment: test.js

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36

Steps to reproduce:

Env: Ubuntu 22.04.5 LTS

1. git clone https://github.com/mozilla/gecko-dev.git && git checkout 88e49196;

2. build SM:
   cat << EOF > .mozconfig
   ac_add_options --enable-application=js
   ac_add_options --enable-optimize
   ac_add_options --enable-debug
   ac_add_options --disable-shared-js
   ac_add_options --enable-js-fuzzilli
   ac_add_options --enable-fuzzing
   ac_add_options --enable-gczeal

   mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-fuzzbuild
   EOF

   export MOZCONFIG=$PWD/.mozconfig
   ./mach build

3. execute the test.js:
   /gecko-dev/obj-fuzzbuild/dist/bin/js --baseline-warmup-threshold=10 --ion-warmup-threshold=100 --ion-check-range-analysis --ion-extra-checks --fuzzing-safe --disable-oom-functions --reprl test.js

Actual results:

[13301] Assertion failure: read(100, &action, 4) == 4, at /home/cjy/Desktop/Engine/gecko-dev/js/src/shell/js.cpp:4135
#01: ???[obj-fuzzbuild/dist/bin/js +0x1cb9830]
#02: ???[obj-fuzzbuild/dist/bin/js +0x1caf80e]
#03: ???[/lib/x86_64-linux-gnu/libc.so.6 +0x29d90]
#04: __libc_start_main[/lib/x86_64-linux-gnu/libc.so.6 +0x29e40]
#05: ???[obj-fuzzbuild/dist/bin/js +0x1c77299]
#06: ??? (???:???)
UndefinedBehaviorSanitizer:DEADLYSIGNAL
==13301==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 0x000000000000 (pc 0x56baa8403848 bp 0x7ffe52db7d90 sp 0x7ffe52db7b00 T13301)
==13301==The signal is caused by a WRITE memory access.
==13301==Hint: address points to the zero page.
#0 0x56baa8403848 in MOZ_CrashSequence(void*, long) /home/cjy/Desktop/Engine/gecko-dev/obj-fuzzbuild/dist/include/mozilla/Assertions.h:267:3
#1 0x56baa8403848 in FuzzilliReprlGetAndRun(JSContext*) /home/cjy/Desktop/Engine/gecko-dev/js/src/shell/js.cpp:4135:3
#2 0x56baa8403848 in ProcessArgs(JSContext*, js::cli::OptionParser*) /home/cjy/Desktop/Engine/gecko-dev/js/src/shell/js.cpp:11643:12
#3 0x56baa8403848 in Shell(JSContext*, js::cli::OptionParser*) /home/cjy/Desktop/Engine/gecko-dev/js/src/shell/js.cpp:12012:12
#4 0x56baa83f980d in main /home/cjy/Desktop/Engine/gecko-dev/js/src/shell/js.cpp:12415:12
#5 0x701d41029d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
#6 0x701d41029e3f in __libc_start_main csu/../csu/libc-start.c:392:3
#7 0x56baa83c1298 in _start (/home/cjy/Desktop/Engine/gecko-dev/obj-fuzzbuild/dist/bin/js+0x1c77298) (BuildId: be9e9b4589d644592347d79539d22736)

==13301==Register values:
rax = 0x0000000000000000 rbx = 0x00007ffe52db7de8 rcx = 0x0000000000001027 rdx = 0x0000701d4121b723
rdi = 0x0000701d4121ca60 rsi = 0x0000000000000000 rbp = 0x00007ffe52db7d90 rsp = 0x00007ffe52db7b00
r8 = 0x0000000000000000 r9 = 0x0000000000000003 r10 = 0x0000000000000000 r11 = 0x0000000000000293
r12 = 0x0000000000000010 r13 = 0x0000000000000010 r14 = 0x0000000000000010 r15 = 0x0000000000000010
UndefinedBehaviorSanitizer can not provide additional info.
SUMMARY: UndefinedBehaviorSanitizer: SEGV /home/cjy/Desktop/Engine/gecko-dev/obj-fuzzbuild/dist/include/mozilla/Assertions.h:267:3 in MOZ_CrashSequence(void*, long)
==13301==ABORTING

Expected results:

no crash

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::JavaScript Engine: JIT' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Iain Ireland [:iain]]

Thanks for the report! However, this is not a bug. The --reprl option is not intended for normal interactive use. Any testcase would crash given those command-line arguments.

The crash is in the Fuzzilli support code here. This is designed to integrate with the Fuzzilli testing harness, which appears to be setting up various file descriptors and then forking the shell in a child process. The testcase crashes when it fails to read an action from the parent process.

If you want to fuzz using Fuzzilli, I would start by looking at the documentation here.

Comment 3

[Jingyi Chen]

Thanks for your nice explanation. However, I'm still encountering a segmentation fault even after removing --reprl, as shown below:
(gdb) bt
#0 0x00005555575ff1f5 in MOZ_CrashSequence (aAddress=0x0, aLine=1367)
at /home/cjy/Desktop/Engine/gecko-dev/obj-fuzzbuild/dist/include/mozilla/Assertions.h:267
#1 MOZ_Crash (aFilename=<optimized out>, aLine=1367,
aReason=0x7fffffdfd2f0 "[unhandlable oom] ShellAllocationMetadataBuilder::build")
at /home/cjy/Desktop/Engine/gecko-dev/obj-fuzzbuild/dist/include/mozilla/Assertions.h:387
#2 js::AutoEnterOOMUnsafeRegion::crash_impl (
reason=0x5555559176c5 "ShellAllocationMetadataBuilder::build")
at /home/cjy/Desktop/Engine/gecko-dev/js/src/vm/JSContext.cpp:1367
#3 0x0000555557a9bdd1 in js::AutoEnterOOMUnsafeRegion::crash (
reason=0x7ffff7a1ca60 <_IO_stdfile_2_lock> "", this=<optimized out>)
at /home/cjy/Desktop/Engine/gecko-dev/obj-fuzzbuild/dist/include/js/Utility.h:311
#4 ShellAllocationMetadataBuilder::build (this=<optimized out>,
cx=0x7ffff753be00, oomUnsafe=...)
at /home/cjy/Desktop/Engine/gecko-dev/js/src/builtin/TestingFunctions.cpp:5132
#5 0x00005555577e937b in JS::Realm::setNewObjectMetadata (
this=0x7ffff4eb7900, cx=0x7ffff753be00, obj=...)
at /home/cjy/Desktop/Engine/gecko-dev/js/src/vm/Realm.cpp:410
#6 0x00005555572e1b99 in js::SetNewObjectMetadata<js::NativeObject> (
--Type <RET> for more, q to quit, c to continue without paging--c
cx=0x7ffff753be00, obj=<optimized out>) at /home/cjy/Desktop/Engine/gecko-dev/js/src/vm/JSObject-inl.h:184
#7 0x000055555762f278 in NewObject (cx=cx@entry=0x7ffff753be00, clasp=clasp@entry=0x5555592c77c0 <js::DebuggerInstanceObject::class_>, proto=proto@entry=..., kind=js::gc::AllocKind::OBJECT16_BACKGROUND, kind@entry=js::gc::AllocKind::OBJECT16, newKind=newKind@entry=js::TenuredObject, objFlags=objFlags@entry=..., allocSite=0x0) at /home/cjy/Desktop/Engine/gecko-dev/js/src/vm/JSObject.cpp:764
#8 0x000055555762ef30 in js::NewObjectWithGivenTaggedProto (cx=0x7ffff753be00, clasp=clasp@entry=0x5555592c77c0 <js::DebuggerInstanceObject::class_>, proto=..., allocKind=allocKind@entry=js::gc::AllocKind::OBJECT16, newKind=newKind@entry=js::TenuredObject, objFlags=objFlags@entry=...) at /home/cjy/Desktop/Engine/gecko-dev/js/src/vm/JSObject.cpp:776
#9 0x0000555557d60bc6 in js::NewObjectWithGivenTaggedProto<(js::NewObjectKind)1> (cx=0x7ffff7a1ca60 <_IO_stdfile_2_lock>, cx@entry=0x5555592c77c0 <js::DebuggerInstanceObject::class_>, clasp=0x557, proto=..., proto@entry=..., objFlags=...) at /home/cjy/Desktop/Engine/gecko-dev/js/src/vm/JSObject-inl.h:355
#10 js::detail::NewObjectWithGivenTaggedProtoForKind<js::DebuggerInstanceObject, (js::NewObjectKind)1> (cx=0x7ffff7a1ca60 <_IO_stdfile_2_lock>, cx@entry=0x7ffff753be00, proto=..., proto@entry=...) at /home/cjy/Desktop/Engine/gecko-dev/js/src/vm/JSObject-inl.h:373
#11 0x0000555557ce6875 in js::NewTenuredObjectWithGivenProto<js::DebuggerInstanceObject> (cx=0x7ffff753be00, proto=...) at /home/cjy/Desktop/Engine/gecko-dev/js/src/vm/JSObject-inl.h:416
#12 js::Debugger::construct (cx=cx@entry=0x7ffff753be00, argc=<optimized out>, vp=<optimized out>) at /home/cjy/Desktop/Engine/gecko-dev/js/src/debugger/Debugger.cpp:4915
#13 0x00005555572f6a8f in CallJSNative (cx=cx@entry=0x7ffff753be00, native=native@entry=0x555557ce6620 <js::Debugger::construct(JSContext*, unsigned int, JS::Value*)>, reason=reason@entry=js::CallReason::Call, args=...) at /home/cjy/Desktop/Engine/gecko-dev/js/src/vm/Interpreter.cpp:493
#14 0x00005555572f6053 in js::InternalCallOrConstruct (cx=0x7ffff753be00, args=..., construct=construct@entry=js::NO_CONSTRUCT, reason=js::CallReason::Call) at /home/cjy/Desktop/Engine/gecko-dev/js/src/vm/Interpreter.cpp:589
#15 0x00005555572f7836 in InternalCall (cx=0x7ffff7a1ca60 <_IO_stdfile_2_lock>, args=..., reason=3072) at /home/cjy/Desktop/Engine/gecko-dev/js/src/vm/Interpreter.cpp:656
#16 0x00005555572f7765 in js::CallFromStack (cx=0x7ffff7a1ca60 <_IO_stdfile_2_lock>, cx@entry=0x7ffff753be00, args=..., reason=4154570531, reason@entry=js::CallReason::Call) at /home/cjy/Desktop/Engine/gecko-dev/js/src/vm/Interpreter.cpp:661
#17 0x00005555581c06cd in js::jit::DoCallFallback (cx=0x7ffff753be00, frame=0x7fffffdfe248, stub=0x7ffff4ea3350, argc=0, vp=0x7fffffdfe1e8, res=...) at /home/cjy/Desktop/Engine/gecko-dev/js/src/jit/BaselineIC.cpp:1705
#18 0x000027d67fe1ff7f in ?? ()
#19 0xfff9800000000000 in ?? ()
#20 0x000000000000006c in ?? ()
#21 0x00007fffffdfe200 in ?? ()
#22 0x000027d67fe44834 in ?? ()
#23 0x0000000000000002 in ?? ()
#24 0x00007fffffdfe248 in ?? ()
#25 0x00007ffff4ea3350 in ?? ()
#26 0x0000000000000000 in ?? ()

Comment 4

[Nicolas B. Pierron [:nbp]]

(In reply to Jingyi Chen from comment #3)

#1 MOZ_Crash (aFilename=<optimized out>, aLine=1367,
aReason=0x7fffffdfd2f0 "[unhandlable oom] ShellAllocationMetadataBuilder::build")
at /home/cjy/Desktop/Engine/gecko-dev/obj-fuzzbuild/dist/include/mozilla/Assertions.h:387

The [unhandlable oom] ShellAllocationMetadataBuilder::build is basically a case where we the allocator reported a failure to make an allocation, and where we deliberatetly chose not to handle it. There could be multiple reasons for not handling some out-of-memory, sometimes due to legacy of punching holes in many API, in other cases because these are small allocations which are not assumed to be frequent enough to cause trouble for our users.

Thus depending on the frequencies of these OOMs, we usually ignore them (when low) or try to fix them (when high), especially if this is impacting our users.

Thus my next question, how frequently do you encounter this precise out-of-memory issue?

Comment 5

[Iain Ireland [:iain]]

Note that this is a shell testcase using testing functions (enableShellAllocationMetadataBuilder, newGlobal), so this doesn't tell us anything about whether users are hitting this case in the wild.

In that context, this is not an interesting failure. [unhandlable OOM] just means that we're in a situation where we've already decided that crashing safely is a better option than trying to untangle ourselves. It's not exploitable.

I recommend filtering out these cases when fuzzing.

Comment 6

[Jingyi Chen]

Thank you for the detailed explanation. That makes perfect sense！