1735707 - AddressSanitizer: use-after-poison [@ JS::GCCellPtr::outOfLineKind]

Status: RESOLVED INCOMPLETE

(Core :: JavaScript Engine, defect)

Description

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Unfortunately I don't have a good reproducible WebAssembly testcase for this. Was on macOS ARM64, AUTOCONF=/usr/local/Cellar/autoconf213/2.13/bin/autoconf213 AR=ar sh ./configure --enable-address-sanitizer --disable-jemalloc --with-ccache --enable-gczeal --enable-debug-symbols --disable-bootstrap --disable-tests on rev 798c43651cb1.

=================================================================
==37332==ERROR: AddressSanitizer: use-after-poison on address 0x107000168004 at pc 0x0001039352e4 bp 0x00016d458840 sp 0x00016d458838
READ of size 1 at 0x107000168004 thread T0
    #0 0x1039352e0 in JS::GCCellPtr::outOfLineKind() const GCAPI.cpp:212
    #1 0x103042a90 in JSScript::needsBodyEnvironment() const JSScript.cpp:279
    #2 0x1042553c8 in js::jit::CompileInfo::CompileInfo(js::jit::CompileRuntime*, JSScript*, JSFunction*, unsigned char*, bool, js::jit::InlineScriptTree*) CompileInfo.h:131
    #3 0x10421b394 in js::jit::Compile(JSContext*, JS::Handle<JSScript*>, js::jit::BaselineFrame*, unsigned char*) Ion.cpp:1898
    #4 0x10421a354 in js::jit::CanEnterIon(JSContext*, js::RunState&) Ion.cpp:1989
    #5 0x10427a148 in js::jit::MaybeEnterJit(JSContext*, js::RunState&) Jit.cpp:167
    #6 0x102b32868 in js::RunScript(JSContext*, js::RunState&) Interpreter.cpp:344
    #7 0x102b6084c in js::ExecuteKernel(JSContext*, JS::Handle<JSScript*>, JS::Handle<JSObject*>, JS::Handle<JS::Value>, js::AbstractFramePtr, JS::MutableHandle<JS::Value>) Interpreter.cpp:727
    #8 0x102dd195c in JS_ExecuteScript(JSContext*, JS::Handle<JSScript*>) CompilationAndEvaluation.cpp:515
    #9 0x102a5b034 in RunFile(JSContext*, char const*, __sFILE*, CompileUtf8, bool) js.cpp:1074
    #10 0x102a59f38 in Process(JSContext*, char const*, bool, FileKind) js.cpp:1663
    #11 0x1029cef18 in main js.cpp:12927
    #12 0x19775542c in start+0x0 (libdyld.dylib:arm64e+0x1842c)

Address 0x107000168004 is a wild pointer.
SUMMARY: AddressSanitizer: use-after-poison GCAPI.cpp:212 in JS::GCCellPtr::outOfLineKind() const
Shadow bytes around the buggy address:
  0x027e0004cfb0: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
  0x027e0004cfc0: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
  0x027e0004cfd0: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
  0x027e0004cfe0: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
  0x027e0004cff0: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
=>0x027e0004d000:[f7]f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
  0x027e0004d010: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
  0x027e0004d020: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
  0x027e0004d030: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
  0x027e0004d040: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
  0x027e0004d050: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
==37332==ABORTING

Guessing Lars or Jon may be able to take a look.

Comment 1

[Lars T Hansen [:lth]]

Test case missing? This looks more like a crash in JS-land than anything, too.

Comment 2

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: testcase.tar.xz

This is the testcase in question but I couldn't reproduce it.

You might have better luck with some variant of the following flags:

--fuzzing-safe --fast-warmup --ion-regalloc=testbed --ion-warmup-threshold=0 --ion-limit-script-size=off --ion-osr=off --ion-licm=off --off-thread-parse-global --disable-parser-deferred-alloc --nursery-bigints=off --blinterp-warmup-threshold=0 --more-compartments --cpu-count=3 --gc-zeal=10,452 --baseline-warmup-threshold=1 --baseline-eager

Comment 3

[Lars T Hansen [:lth]]

/me counts 16 flags, 2^16 = 65536, let's hope we don't have to try all combinations!

Comment 4

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Well, it triggered with that specific combination, but in all my years of experience with fuzzbugs, I've had to tweak a handful manually, or switch --baseline-eager to --ion-eager or even add --no-threads or --ion-offthread-compile=off etc.

Comment 5

[Jon Coppeard (:jonco)]

Not specifically GC related. It looks like PrivateScriptData's gcThings array contains a bad pointer and we're crashing trying to get the alloc kind. I don't know why that would be since this is traced in PrivateScriptData::trace.

Comment 6

[Jon Coppeard (:jonco)]

CC Ted for famililarity with JSScript internals.

Comment 7

[Andrew McCreight [:mccr8]]

Steven, is there somebody who could investigate this? It has been stalled for almost a month. Thanks.

Comment 8

[Ted Campbell [:tcampbell]]

This failure stack is pretty odd to begin with. The ExecuteKernel -> RunScript -> MaybeEnterJit sequence only happens once and at the very start. As a result, it only seems that parser and GC could be involved since we failure before any JS code executes (so WASM is clear of blame here too).

The ASAN failure is a gc::Chunk of js::Scope (which are the only out-of-line trace kind used by scripts here). This is a surprising failure very early on and the wrapper-JS code is not particularly interesting (just long).

Comment 9

[Ted Campbell [:tcampbell]]

Gary, was this a single crash, or have you been able to reproduce even once?

Also, what compiler are you using in your setup for this? This is an odd failure that more resembles miscompile or memory error. I'm a bit stumped with the data we have here.

Comment 10

[Steven DeTar [:sdetar]]

Since Ted investigated this I am clearing the NI for me (:sdetar).

Comment 11

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

It happened only once, I couldn't reproduce it again.

$ clang --version
Apple clang version 12.0.5 (clang-1205.0.22.11)
Target: arm64-apple-darwin20.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

On macOS 11.6.

Comment 12

[Daniel Veditz [:dveditz] out until Nov 10]

Have to set this aside for now as we haven't been able to get anywhere. Please reopen if it happens again, especially if you get a more reproducible testcase.