This bug was filed from the Socorro interface and is report bp-65fecab3-4998-4724-8c55-ce7620170520. ============================================================= Crashing Thread (0) Frame Module Signature Source 0 xul.dll js::gc::AtomMarkingRuntime::markAtom(JSContext*, js::gc::TenuredCell*) js/src/gc/AtomMarking.cpp:183 1 xul.dll NewFunctionClone js/src/jsfun.cpp:2025 2 xul.dll js::CloneFunctionObjectIfNotSingleton(JSContext*, JS::Handle<JSFunction*>, JS::Handle<JSObject*>, JS::Handle<JSObject*>, js::NewObjectKind) js/src/jsfuninlines.h:89 3 xul.dll js::Lambda(JSContext*, JS::Handle<JSFunction*>, JS::Handle<JSObject*>) js/src/vm/Interpreter.cpp:4356 4 xul.dll Interpret js/src/vm/Interpreter.cpp:3531 5 xul.dll js::RunScript(JSContext*, js::RunState&) js/src/vm/Interpreter.cpp:394 6 xul.dll js::ExecuteKernel(JSContext*, JS::Handle<JSScript*>, JSObject&, JS::Value const&, js::AbstractFramePtr, JS::Value*) js/src/vm/Interpreter.cpp:677 7 xul.dll js::Execute(JSContext*, JS::Handle<JSScript*>, JSObject&, JS::Value*) js/src/vm/Interpreter.cpp:709 8 @0xc002f77 this cross-platform signature is showing up since 54 builds & looking related to bugs 1324002 & 1325050.

Clear UAF in 54

Jon can you take a look? Not sure why bhackett got an NI? Was his patch in the bisect?

(In reply to Naveed Ihsanullah [:naveed] from comment #2) bhackett wrote the AtomMarkingRuntime code in bug 1324002.

Brian, can you look at this bug? It's a sec-high that we'd like to get fixed soon.

Naveed or jonco, Does this still seem actionable? I'm calling it wontfix for 56 since it doesn't seem like there is a fix in progress and we're midway through the 57 beta cycle. We could still take a patch for 57/58.

Bug 1384544 is probably the same thing and there are some suggestions that this may be XDR corruption.

Hi Naveed: I have assigned these security bugs to you to reassign them to appropriate developers in your team to investigate and fix them. Thanks! Wennie

Taking as part of the XDR crash collection. Once Bug 1418894 rides beta for a few more days we can look at what crashes remain and reassess.

Looks like there's still some lingering crashes in later 58 betas.

Still crashing in 59beta and 60nightly, for the js::CloneFunctionReuseScript signature only. Some are null-derefs, some are wildptrs, some are non-nullptr non-ptrs (0x200000000 and the like). The other signature seems to be 54 only. Thoughts? Next steps?

So these remaining crashes seem unrelated to the XDR investigation before. These crashes still seem to be triggering through JSOP_LAMBDA running non-sense code. I'm thinking we should investigate perf impact of making a release assert that [1] is a JSFunction. I'm not sure why it would a bad value, but we might be able to makes these crashes less scary at least. [1] https://searchfox.org/mozilla-central/rev/74b7ffee403c7ffd05b8b476c411cbf11d134eb9/js/src/vm/JSScript-inl.h#114

Can you re-purpose/title this bug for that, or perhaps better spin off a new bug to add a release-assert (if the perf impact is ok)? Thanks

Created the follow-up bug for a runtime assertion. Thanks for following up on this stuff. Patch should be up in next few days.

Ted - any progress?

I have now put a patch up on Bug 1438880. None of this is getting to root causes, but it should turn wildptr crashes into release asserts. This should help us see if there are other bugs hiding behind this signature as well as bucket these crashes into sources a little better. In this case, failures on the asserts being added indicates ScriptData (a jemalloc'd memory buffer) has been corrupted.

Is this still worth tracking?

Remaining crashes are Android which I've opened Bug 1456249 to look at. The bulk of the crashes this bug saw have been fixed. There are also some release asserts tripping in Bug 1456255 which need follow-up.