Bugzilla

Note that 0x4000000000000 has a high bit set (outside the 48-bit address space). If I'm doing my math right, it's what you expect as the result of `NullValue.toObject()` (in a non-debug build). If we reliably crash by dereferencing this value, it's probably not exploitable.

That's consistent with the ASAN output in the initial report: `rdi = 0x0004000000000028` is precisely what we'd expect if we unboxed a null value where we expected a JSFunction, then tried to load the script from that 'function'. (NativeJitInfoOrInterpretedScriptSlot is the [third](https://searchfox.org/mozilla-central/rev/ec8a326713f60dec138a3e3383b03ac739870fc7/js/src/vm/JSFunction.h#100) reserved slot. Offset 0x0 is the shape, 0x8 is the slots pointer, 0x10 is the elements pointer, and then three reserved slots gets us to an offset of 0x28 from the base pointer.)

Note that 0x4000000000000 has a high bit set (outside the 48-bit address space). If I'm doing my math right, it's what you expect as the result of `NullValue.toObject()` (in a non-debug build). If we reliably crash by dereferencing this value, it's probably not exploitable.

That's consistent with the ASAN output in the initial report: `rdi = 0x0004000000000028` is precisely what we'd expect if we unboxed a null value where we expected a JSFunction, then tried to load the script from that 'function'. (NativeJitInfoOrInterpretedScriptSlot is the [third](https://searchfox.org/mozilla-central/rev/ec8a326713f60dec138a3e3383b03ac739870fc7/js/src/vm/JSFunction.h#100) reserved slot. Offset 0x0 is the shape, 0x8 is the slots pointer, 0x10 is the elements pointer, and then three reserved slots gets us to an offset of 0x28 from the base pointer.)

Edit: I see a [number](https://searchfox.org/mozilla-central/rev/ec8a326713f60dec138a3e3383b03ac739870fc7/js/src/vm/AsyncIteration.h#330-331) [of](https://searchfox.org/mozilla-central/rev/ec8a326713f60dec138a3e3383b03ac739870fc7/js/src/vm/AsyncIteration.h#515) [places](https://searchfox.org/mozilla-central/rev/ec8a326713f60dec138a3e3383b03ac739870fc7/js/src/vm/AsyncIteration.h#428) where we store NullValue in AsyncGeneratorObject slots. Without digging into the details of the bug, it seems plausible to me that calling a method in the wrong state would deterministically return this specific bogus value.