1678582 - Crash [@ ??] with Cranelift

Status: RESOLVED FIXED

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

Description

[Christian Holler (:decoder)]

The attached testcase crashes on mozilla-central revision 36ef6c97da5b (build with --enable-optimize --enable-fuzzing --enable-cranelift --enable-tests --enable-valgrind --enable-gczeal --disable-jemalloc --enable-debug, run with --no-threads --fuzzing-safe --wasm-compiler=optimizing test.js).

Backtrace:

==2768==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 0x000000000000 (pc 0x0d02e5d8d0b0 bp 0xffffd2d87660 sp 0xffffd2d87620 T2768)
==2768==The signal is caused by a READ memory access.
==2768==Hint: address points to the zero page.
    #0 0xd02e5d8d0b0  (<unknown module>)

UndefinedBehaviorSanitizer can not provide additional info.
SUMMARY: UndefinedBehaviorSanitizer: SEGV (<unknown module>) 
==2768==ABORTING

This happens fairly often, so this is likely a recent regression. Reproduces only on Cranelift. Marking s-s due to missing stack.

Comment 1

[Christian Holler (:decoder)]

Attachment: Testcase

Comment 2

[Lars T Hansen [:lth]]

From the flags I'm guessing this is on device, so it goes to Julian. But if I'm wrong about that please LMK and I can take a look.

Comment 3

[Julian Seward [:jseward]]

For --compiler=baseline, the test case is rejected thusly:

test.js:9:14 CompileError: at offset 50: indirect calls must go through a table of 'funcref'

For --compiler=cranelift, the input isn't rejected, and we wind up crashing in what
looks like CL-generated code. So I'm wondering if this is another wasmparser bug,
in that the input should have been rejected, but wasn't, and was then presumably
miscompiled.

Comment 4

[Lars T Hansen [:lth]]

Attachment: Test case as wasm binary

Comment 5

[Lars T Hansen [:lth]]

Disassembly:

[lhansen@yojimbo tmp]$ wasm2wat --no-check test.wasm 
(module
  (type (;0;) (func (result i32 i32)))
  (func $main (type 0) (result i32 i32)
    i32.const 0
    call_indirect (type 0)
    call_indirect (type 0)
    call_indirect (type 0)
    call_indirect (type 0)
    call_indirect (type 0)
    br_if 0 (;@0;)
    call_indirect (type 0)
    return)
  (table (;0;) 12 255 externref)
  (export "t1" (table 0))
  (export "main" (func $main)))

The table indeed has type externref, which is wrong. wasm2wat complains if I allow it to run validation, as it should.

Comment 6

[Julian Seward [:jseward]]

This bug, and bug 1673555, will be fixed once bug 1680509 lands. 1680509 is ostensibly just a revendor to our private wasmtime/wasm-tools/regalloc.rs repos, and contains no test cases, so we'll have to land this bug's test case separately when the time is right.

Comment 7

[Julien Cristau [:jcristau]]

Closing based on comment 6.

Does this affect branches?

Comment 8

[BugBot [:suhaib / :marco]]

As part of a security bug pattern analysis, we are requesting your help with a high level analysis of this bug. It is our hope to develop static analysis (or potentially runtime/dynamic analysis) in the future to identify classes of bugs.

Please visit this google form to reply.