1883865 - Assertion failure: end_ <= other.begin_ || begin_ >= other.end_ || (begin_ > other.begin_ && end_ < other.end_) || (other.begin_ > begin_ && other.end_ < end_), at wasm/WasmCodegenTypes.h:747 or Crash [@ InlineForwardListIterator] in BacktrackingAllocator

Status: VERIFIED FIXED

(Core :: JavaScript: WebAssembly, defect, P1)

Description

[Christian Holler (:decoder)]

The attached testcase crashes on mozilla-central revision 20240306-099f52f30c39 (build with fuzzing-debug, run with --no-threads --wasm-compiler=baseline).

Backtrace:

    ==9019==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 0x000000000000 (pc 0x558c8638961a bp 0x7fffcb43dee0 sp 0x7fffcb43de80 T9019)
        #0 0x558c8638961a in operator< /js/src/wasm/WasmCodegenTypes.h:745:5
        #1 0x558c8638961a in operator()<js::wasm::TryNote, js::wasm::TryNote *> /builds/worker/fetches/sysroot-x86_64-linux-gnu/usr/lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/predefined_ops.h:90:22
        #2 0x558c8638961a in __unguarded_linear_insert<js::wasm::TryNote *, __gnu_cxx::__ops::_Val_less_iter> /builds/worker/fetches/sysroot-x86_64-linux-gnu/usr/lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/stl_algo.h:1828:14
        #3 0x558c8638961a in void std::__insertion_sort<js::wasm::TryNote*, __gnu_cxx::__ops::_Iter_less_iter>(js::wasm::TryNote*, js::wasm::TryNote*, __gnu_cxx::__ops::_Iter_less_iter) /builds/worker/fetches/sysroot-x86_64-linux-gnu/usr/lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/stl_algo.h:1855:6
        #4 0x558c862a56a6 in __sort<js::wasm::TryNote *, __gnu_cxx::__ops::_Iter_less_iter> /builds/worker/fetches/sysroot-x86_64-linux-gnu/usr/lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/stl_algo.h:1971:4
        #5 0x558c862a56a6 in sort<js::wasm::TryNote *> /builds/worker/fetches/sysroot-x86_64-linux-gnu/usr/lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/stl_algo.h:4834:7
        #6 0x558c862a56a6 in js::wasm::ModuleGenerator::finishMetadataTier() /js/src/wasm/WasmGenerator.cpp:958:3
        #7 0x558c862a7676 in js::wasm::ModuleGenerator::finishCodeTier() /js/src/wasm/WasmGenerator.cpp:1059:8
        #8 0x558c862a965b in js::wasm::ModuleGenerator::finishModule(js::wasm::ShareableBytes const&, JS::OptimizedEncodingListener*) /js/src/wasm/WasmGenerator.cpp:1174:29
        #9 0x558c8626a1ed in js::wasm::CompileBuffer(js::wasm::CompileArgs const&, js::wasm::ShareableBytes const&, mozilla::UniquePtr<char [], JS::FreePolicy>*, mozilla::Vector<mozilla::UniquePtr<char [], JS::FreePolicy>, 0ul, js::SystemAllocPolicy>*, JS::OptimizedEncodingListener*) /js/src/wasm/WasmCompile.cpp:815:13
        #10 0x558c862ed4cf in js::WasmModuleObject::construct(JSContext*, unsigned int, JS::Value*) /js/src/wasm/WasmJS.cpp:1494:7
        #11 0x558c84bd3bf4 in CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), js::CallReason, JS::CallArgs const&) /js/src/vm/Interpreter.cpp:479:13
        [...]
        #25 0x558c84a08cd0 in main /js/src/shell/js.cpp:11758:12
    
    UndefinedBehaviorSanitizer can not provide additional info.
    SUMMARY: UndefinedBehaviorSanitizer: SEGV /js/src/wasm/WasmCodegenTypes.h:745:5 in operator<
    ==9019==ABORTING

Marking s-s because in non-debug this crashes in the backtracking allocator.

Comment 1

[Christian Holler (:decoder)]

Attachment: Detailed Crash Information

Comment 2

[Christian Holler (:decoder)]

Attachment: Testcase

Comment 3

[Christian Holler (:decoder)]

This is an automated crash issue comment:

Summary: Crash [@ InlineForwardListIterator]
Build version: mozilla-central revision 20240305-63e18d5ef9ec
Build type: fuzzing-asan-opt
Runtime options: --no-threads --wasm-compiler=baseline

Backtrace:

==639==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000008 (pc 0x55c327c835c8 bp 0x7fff7ca71900 sp 0x7fff7ca71870 T0)
==639==The signal is caused by a READ memory access.
    #0 0x55c327c835c8 in InlineForwardListIterator /js/src/jit/InlineList.h:151:29
    #1 0x55c327c835c8 in begin /js/src/jit/InlineList.h:58:35
    #2 0x55c327c835c8 in rangesBegin /js/src/jit/BacktrackingAllocator.h:460:70
    #3 0x55c327c835c8 in firstRange /js/src/jit/BacktrackingAllocator.h:462:58
    #4 0x55c327c835c8 in js::jit::BacktrackingAllocator::tryMergeBundles(js::jit::LiveBundle*, js::jit::LiveBundle*) /js/src/jit/BacktrackingAllocator.cpp:1870:36
    #5 0x55c327c87581 in js::jit::BacktrackingAllocator::mergeAndQueueRegisters() /js/src/jit/BacktrackingAllocator.cpp:2163:14
    #6 0x55c327ca1191 in js::jit::BacktrackingAllocator::go() /js/src/jit/BacktrackingAllocator.cpp:4549:8
    #7 0x55c32840f536 in js::jit::GenerateLIR(js::jit::MIRGenerator*) /js/src/jit/Ion.cpp:1551:23
    #8 0x55c328cbeb0d in js::wasm::IonCompileFunctions(js::wasm::ModuleEnvironment const&, js::wasm::CompilerEnvironment const&, js::LifoAlloc&, mozilla::Vector<js::wasm::FuncCompileInput, 8ul, js::SystemAllocPolicy> const&, js::wasm::CompiledCode*, mozilla::UniquePtr<char [], JS::FreePolicy>*) /js/src/wasm/WasmIonCompile.cpp:9362:23
    #9 0x55c328c5e181 in ExecuteCompileTask(js::wasm::CompileTask*, mozilla::UniquePtr<char [], JS::FreePolicy>*) /js/src/wasm/WasmGenerator.cpp:729:12
    #10 0x55c328c5f95b in locallyCompileCurrentTask /js/src/wasm/WasmGenerator.cpp:784:8
    #11 0x55c328c5f95b in js::wasm::ModuleGenerator::finishFuncDefs() /js/src/wasm/WasmGenerator.cpp:915:24
    #12 0x55c328c0f4b4 in bool DecodeCodeSection<js::wasm::Decoder>(js::wasm::ModuleEnvironment const&, js::wasm::Decoder&, js::wasm::ModuleGenerator&) /js/src/wasm/WasmCompile.cpp:785:13
    #13 0x55c328c0e7e5 in js::wasm::CompileBuffer(js::wasm::CompileArgs const&, js::wasm::ShareableBytes const&, mozilla::UniquePtr<char [], JS::FreePolicy>*, mozilla::Vector<mozilla::UniquePtr<char [], JS::FreePolicy>, 0ul, js::SystemAllocPolicy>*, JS::OptimizedEncodingListener*) /js/src/wasm/WasmCompile.cpp:807:8
    #14 0x55c328cdc1dd in js::WasmModuleObject::construct(JSContext*, unsigned int, JS::Value*) /js/src/wasm/WasmJS.cpp:1494:7
    #15 0x55c3267a1455 in CallJSNative /js/src/vm/Interpreter.cpp:479:13
    [...]

Comment 4

[Christian Holler (:decoder)]

This is an automated crash issue comment:

Summary: Crash [@ InlineForwardListIterator]
Build version: mozilla-central revision 20240305-63e18d5ef9ec
Build type: fuzzing-asan-opt
Runtime options: --no-threads --wasm-compiler=baseline

Backtrace:

==639==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000008 (pc 0x55c327c835c8 bp 0x7fff7ca71900 sp 0x7fff7ca71870 T0)
==639==The signal is caused by a READ memory access.
    #0 0x55c327c835c8 in InlineForwardListIterator /js/src/jit/InlineList.h:151:29
    #1 0x55c327c835c8 in begin /js/src/jit/InlineList.h:58:35
    #2 0x55c327c835c8 in rangesBegin /js/src/jit/BacktrackingAllocator.h:460:70
    #3 0x55c327c835c8 in firstRange /js/src/jit/BacktrackingAllocator.h:462:58
    #4 0x55c327c835c8 in js::jit::BacktrackingAllocator::tryMergeBundles(js::jit::LiveBundle*, js::jit::LiveBundle*) /js/src/jit/BacktrackingAllocator.cpp:1870:36
    #5 0x55c327c87581 in js::jit::BacktrackingAllocator::mergeAndQueueRegisters() /js/src/jit/BacktrackingAllocator.cpp:2163:14
    #6 0x55c327ca1191 in js::jit::BacktrackingAllocator::go() /js/src/jit/BacktrackingAllocator.cpp:4549:8
    #7 0x55c32840f536 in js::jit::GenerateLIR(js::jit::MIRGenerator*) /js/src/jit/Ion.cpp:1551:23
    #8 0x55c328cbeb0d in js::wasm::IonCompileFunctions(js::wasm::ModuleEnvironment const&, js::wasm::CompilerEnvironment const&, js::LifoAlloc&, mozilla::Vector<js::wasm::FuncCompileInput, 8ul, js::SystemAllocPolicy> const&, js::wasm::CompiledCode*, mozilla::UniquePtr<char [], JS::FreePolicy>*) /js/src/wasm/WasmIonCompile.cpp:9362:23
    #9 0x55c328c5e181 in ExecuteCompileTask(js::wasm::CompileTask*, mozilla::UniquePtr<char [], JS::FreePolicy>*) /js/src/wasm/WasmGenerator.cpp:729:12
    #10 0x55c328c5f95b in locallyCompileCurrentTask /js/src/wasm/WasmGenerator.cpp:784:8
    #11 0x55c328c5f95b in js::wasm::ModuleGenerator::finishFuncDefs() /js/src/wasm/WasmGenerator.cpp:915:24
    #12 0x55c328c0f4b4 in bool DecodeCodeSection<js::wasm::Decoder>(js::wasm::ModuleEnvironment const&, js::wasm::Decoder&, js::wasm::ModuleGenerator&) /js/src/wasm/WasmCompile.cpp:785:13
    #13 0x55c328c0e7e5 in js::wasm::CompileBuffer(js::wasm::CompileArgs const&, js::wasm::ShareableBytes const&, mozilla::UniquePtr<char [], JS::FreePolicy>*, mozilla::Vector<mozilla::UniquePtr<char [], JS::FreePolicy>, 0ul, js::SystemAllocPolicy>*, JS::OptimizedEncodingListener*) /js/src/wasm/WasmCompile.cpp:807:8
    #14 0x55c328cdc1dd in js::WasmModuleObject::construct(JSContext*, unsigned int, JS::Value*) /js/src/wasm/WasmJS.cpp:1494:7
    #15 0x55c3267a1455 in CallJSNative /js/src/vm/Interpreter.cpp:479:13
    [...]

Comment 5

[Yury Delendik (:yury)]

Minimized test case (--wasm-compiler=baseline):

new WebAssembly.Module(wasmTextToBinary(`
(module
  (func
      try_table $l3
        try_table $l4
          try_table $l5 (catch_all 0)
          end
        end
      end
  )
)
`))

Comment 6

[Yury Delendik (:yury)]

Different minimal case but produces different stack trace and --wasm-compiler=ion:

new WebAssembly.Module(wasmTextToBinary(`
(module
    (func (param f64)
      try_table (catch_all 0)
        loop 
          try_table (catch_all 0) 
            memory.size
            drop
          end
        end
      end
    )
    (memory i64 1 1)
  )
`))

Comment 7

[Yury Delendik (:yury)]

(In reply to Christian Holler (:decoder) from comment #3)

Runtime options: --no-threads --wasm-compiler=baseline

Backtrace:

==639==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000008 (pc 0x55c327c835c8 bp 0x7fff7ca71900 sp 0x7fff7ca71870 T0)
==639==The signal is caused by a READ memory access.
    #0 0x55c327c835c8 in InlineForwardListIterator /js/src/jit/InlineList.h:151:29

...

    #7 0x55c32840f536 in js::jit::GenerateLIR(js::jit::MIRGenerator*) /js/src/jit/Ion.cpp:1551:23
    #8 0x55c328cbeb0d in js::wasm::IonCompileFunctions(js::wasm::ModuleEnvironment const&, js::wasm::CompilerEnvironment const&, 

I noticed that test is running with --wasm-compiler=baseline which shall disable Ion, but stack trace clearly shows Ion is running. Is it a mistake?

Comment 8

[Yury Delendik (:yury)]

Attachment: Bug 1883865 - Fix tryNote sorting assert. r?rhunt

Comment 9

[Yury Delendik (:yury)]

Baseline defect was introduced by bug 1771013. The MOZ_ASSERT just detects wrong tryNote ordering. In release mode, the worst thing that will happen is wasm exception will not be caught.

Comment 10

[Christian Holler (:decoder)]

(In reply to Yury Delendik (:yury) from comment #7)

I noticed that test is running with --wasm-compiler=baseline which shall disable Ion, but stack trace clearly shows Ion is running. Is it a mistake?

I just double-checked and this is likely a mistake by manual copy/paste. The test run in comment 0 is with baseline but the one in comment 3/4 is with ion.

Comment 11

[Christian Holler (:decoder)]

(In reply to Yury Delendik (:yury) from comment #9)

Baseline defect was introduced by bug 1771013. The MOZ_ASSERT just detects wrong tryNote ordering. In release mode, the worst thing that will happen is wasm exception will not be caught.

Is the issue in comment 3/4 with ion a different bug then, triggered by the same test?

Comment 12

[Yury Delendik (:yury)]

(In reply to Christian Holler (:decoder) from comment #11)

Is the issue in comment 3/4 with ion a different bug then, triggered by the same test?

The same test, yes. Opened bug 1883944 for Ion issue.

Comment 13

[Ryan Hunt [:rhunt]]

For the baseline issue, I believe this is not security sensitive because while this assertion failure could cause an exception to go to the wrong 'catch handler', this is mitigated by our catch handlers being able to handle any kind of exception. So it would possibly result in incorrect execution of the users program, but not breaking sandbox guarantees.

However, I don't know about the Ion bug yet and that's reference on this bug, so I don't think it makes sense to open this whole bug up. Maybe we could file a separate non-sec bug for the baseline one?

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d57da3d63783
Fix tryNote sorting assert. r=rhunt

Comment 15

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

https://hg.mozilla.org/mozilla-central/rev/d57da3d63783

Comment 17

[Bugmon [:jkratzer for issues]]

Verified bug as fixed on rev mozilla-central 20240307095557-aded201f11ec.
Removing bugmon keyword as no further action possible. Please review the bug and re-add the keyword for further analysis.