1266679 - AddressSanitizer: global-buffer-overflow on address 0x7f0331a3d960 at pc 0x7f03304bb2ea bp 0x7ffdae8a6710 sp 0x7ffdae8a6708

Status: RESOLVED INCOMPLETE

(Core :: JavaScript Engine, defect)

Description

[Carsten Book [:Tomcat]]

Attachment: AddressSanitizer: global-buffer-overflow on address 0x7f0331a3d960 at pc 0x7f03304bb2ea bp 0x7ffdae8a6710 sp 0x7ffdae8a6708

Bughunter run into a lot of js crashes on https://storage.googleapis.com/windowsosxpornvirusdetectedharmfulforsystemainalertvirusneed15/MAC/appleuk.html (somehow this url looks strange to me). 

We have some ASAN Reports that are AddressSanitizer: global-buffer-overflow on address 0x at pc 0x bp 0x sp 0x

So far i was not able to reproduce since the url is gone but the number of crashes is remarkable (not sure if someone tried something here or maybe a user trap ? 

Will attach some stacks here, maybe we can figure out from this what goes on there.

Comment 1

[Carsten Book [:Tomcat]]

Attachment: bughunter log

Comment 2

[Carsten Book [:Tomcat]]

Attachment: windows crash report

Comment 3

[Carsten Book [:Tomcat]]

signatures for this crash so far discovered by bughunter are:

js::jit::MacroAssembler::initGCThing js::jit::MacroAssembler::createGCObject js::jit::CodeGenerator::visitNewArray js::jit::LNewArray::accept js::jit::CodeGenerator::generateBody

js::jit::MacroAssembler::initGCThing js::jit::MacroAssembler::createGCObject js::jit::CodeGenerator::visitNewArray js::jit::CodeGenerator::generateBody js::jit::CodeGenerator::generate


js::TraceManuallyBarrieredGenericPointerEdge js::jit::AssemblerX86Shared::TraceDataRelocations js::jit::JitCode::traceChildren js::gc::StoreBuffer::MonoTypeBuffer<js::gc::StoreBuffer::WholeCellEdges>::trace js::Nursery::collect

js::jit::MacroAssembler::initGCThing js::jit::CodeGenerator::visitNewArray js::jit::LNewArray::accept js::jit::CodeGenerator::generateBody js::jit::CodeGenerator::generate

JS::DispatchTraceKindTyped<TraceManuallyBarrieredEdgeFunctor, JSTracer*&, js::gc::Cell**&, char const*&> js::TraceGenericPointerRoot js::jit::MarkIonJSFrame js::jit::MarkJitActivation js::jit::MarkJitActivations

js::TraceManuallyBarrieredGenericPointerEdge TraceDataRelocations js::jit::JitCode::traceChildren js::gc::StoreBuffer::MonoTypeBuffer<js::gc::StoreBuffer::WholeCellEdges>::trace js::Nursery::collect

js::TraceGenericPointerRoot js::jit::MarkJitActivations js::gc::GCRuntime::markRuntime js::Nursery::collect js::gc::GCRuntime::minorGCImpl

MapAllocToTraceKind getTraceKind getTraceKind js::TraceManuallyBarrieredGenericPointerEdge(JSTracer*, js::gc::Cell**, char const*) TraceDataRelocations(JSTracer*, unsigned char*, js::jit::CompactBufferReader&)

js::TenuringTracer::traverse<JSObject> js::DispatchTyped<js::TenuringTraversalFunctor<JS::Value>, js::TenuringTracer* const> DispatchToTracer<JS::Value> js::TraceRootRange<JS::Value> js::InterpreterFrame::trace

Comment 4

[Carsten Book [:Tomcat]]

oh and for platform this seems linux and windows and nightly only so far

Comment 5

[Jan de Mooij [:jandem]]

Does bughunter submit crash reports, to crash-stats?

Looks like random GC crashes. Probably hard to tell much from these stacks, but I'll take a closer look soon.

I agree the URL and everything about this seems fishy and scary.

Comment 6

[Carsten Book [:Tomcat]]

(In reply to Jan de Mooij [:jandem] from comment #5)
> Does bughunter submit crash reports, to crash-stats?
> 

Bob: i think its more the other way that we get the urls from crash stats but don't submit data back or ?

Comment 7

[Jan de Mooij [:jandem]]

Maybe it doesn't mean much, but the website did use Flash I think:

  Spider: HTTP Request:  <..snip..> /MAC/player.swf

Tomcat, does this machine have Flash installed/enabled?

Comment 8

[Bob Clary [:bc] (inactive)]

We uninstalled Flash a while back so this shouldn't have anything to do with that. I don't see any plugin instantiations in the log though. Funny that we fetched it even if it isn't installed though.

Tomcat: I don't see this in the most recent crashes. When did this happen? Are there other related crashes on the same url? Have you captured the html?

We get urls from Socorro but don't submit reports back. As far as I know there isn't an automatic means of doing that.

Comment 9

[Carsten Book [:Tomcat]]

(In reply to Bob Clary [:bc:] from comment #8)

> Tomcat: I don't see this in the most recent crashes. When did this happen?

Bughunter displays this for me today the crashes in the last 48 hour (or so)

> Are there other related crashes on the same url? 

yeah see comment #3

> Have you captured the html?
 
nope, the page was gone when i tried to check the page

Comment 10

[Jan de Mooij [:jandem]]

On crash-stats we have a shutdown hang with that URL:

https://crash-stats.mozilla.com/report/index/e7613d0e-e1a3-4865-bb4b-6ad4f2160416

And a crash in trf.dylib with a similar URL:

https://crash-stats.mozilla.com/report/index/2dd44b89-ba66-4a7a-bbd9-4e7742160409
https://storage.googleapis.com/macosxpornvirusdetectedharmfulforsystem/mac/osx/error/96540/appleuk.html 

No other crash reports.

Comment 11

[Andrew McCreight [:mccr8]]

This vaguely looks like it could be a regression from bug 1259180. Jonco fixed at least one missing trace thing in JIT code.

Comment 12

[Andrew McCreight [:mccr8]]

Bob, would it be possible to have Bughunter save pages? Just guessing by the URL, I wonder if this is a malware site that got taken down quickly by Google, so it would be nice if we had some test case to go on. It could even do something like save the page, try loading it, and then discarding it if the saved thing doesn't crash.

Comment 13

[Andrew McCreight [:mccr8]]

ni? for my previous comment. Obviously it is too late for this bug, but in the future it might come in handy.

Comment 14

[Christian Holler (:decoder)]

For cases like this bug, it would probably be even helpful to have the saved page if it doesn't crash. Just so we can see what the page was possibly doing, even though saving broke it.

Comment 15

[Bob Clary [:bc] (inactive)]

Saving a page that would reproduce the crash is problematic but if decoder is right that even a page that is munged by wget would be useful we could probably do this. We run all of the urls through a proxy which might also be a means of obtaining the page. I'll file a bug on me to do this. We will have to clean them out fairly often. So far this year we've seen 100K+ crashes and I'm not sure how much storage this will take.

Comment 16

[Andrew McCreight [:mccr8]]

(In reply to Bob Clary [:bc:] from comment #15)
> So far this year we've seen 100K+
> crashes and I'm not sure how much storage this will take.

We would only need pages saved for times when AddressSanitizer detects a use-after-free or a heap-buffer-overflow. Those don't seem to be very common.

Comment 17

[Andrew McCreight [:mccr8]]

With no testcase, I can't imagine we can do anything with this.

Comment 18

[Daniel Veditz [:dveditz]]

Is there anything we can actually do here if the reproducing page is gone? Maybe it's time to mark INCOMPLETE.