895437 - TypedArrayTemplate<js::uint8_clamped>::copyFromTypedArray js::GetElement| crash in mozilla::dom::NodeBinding::get_childNodes

Status: RESOLVED DUPLICATE of bug 898832

(Core :: JavaScript Engine, defect)

Description

[Carsten Book [:Tomcat]]

Attachment: win xp stack from bughutner

Bughunter found a crash in TypedArrayTemplate<js::uint8_clamped>::copyFromTypedArray js::GetElement on http://tygodnik.onet.pl/32%2C0%2C80578%2Cproboszcz_przed_prawem%2Cartykul.html 

Loading this page crash Firefox Beta opt/debug builds on windows on load within seconds.

Aurora and Nightly seem fine. 

The Crash on XP is rated exploitablity: high - on windows 7 i got as crashreport with an beta opt build https://crash-stats.mozilla.com/report/index/a8ede5c3-7e90-4b70-96c9-a96e52130718

Alex, Al, Dan: Could someone look at this in case this really something bad on the beta branch as the exploitablity rating for windows xp suggests

Comment 1

[Carsten Book [:Tomcat]]

btw the exploitable raiting is there because of the crash adress 

Crash reason:  EXCEPTION_ACCESS_VIOLATION_EXEC
Crash address: 0xfffffffffdfdfdfd

Comment 2

[Carsten Book [:Tomcat]]

and also don't crash Firefox 22 Release Build - so maybe something new

Comment 3

[Daniel Veditz [:dveditz]]

Was this using a debug build? 0xfdfdfdfd is a value the MS allocators use as a guard block around mallocs, I thought only in debug mode. The program is off in the weeds and this is usually exploitable, as you noted in comment 1. (for reference this is a useful page: http://www.softwareverify.com/memory-bit-patterns.php )

the attached stack trace doesn't seem related to the Socorro report, but in the Socorro report I have a hard time believing ToLowerCaseHelper calls get_childNodes() so I think we're looking at a corrupt stack.

If it's not a problem in 22 and doesn't seem to happen on 24/25 I wonder if it was a regression introduced near the end of 23 and then fixed in 24, or if it was introduced on the 23 branch in Aurora or Beta by backporting other fixes that happened to depend on other changes that weren't backported?

We should test this...
a) try a m-c nightly from the end of the Fx23 cycle
b) if no crash try an early fx 23 Aurora build
c) if no crash try a late fx 23 Aurora build
d) if no crash try an early fx23 Beta build

If a) crashes then it might be easy to identify a fix for the bug in a later fx24 m-c build. If it's one of the others we'll have to identify which back-ported change caused it.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Is this Windows-only?  I can't seem to reproduce in a Mac beta build....

Comment 5

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

I also cannot reproduce this with 23.0b6 on Win7 nor WinXP SP3, all tested with a new profile.

Comment 6

[Bob Clary [:bc] (inactive)]

The crashes found on bughunter are always with debug builds.

The exploitable crash with fence post address was XP only.  Windows 7 showed the crash with the same reason at js:GetElement with a 0x42 address. Linux 64bit showed a crash at @0x0 | mozilla::dom::NodeBinding::get_childNodes js::GetElement. Of the 3, xp is the most reliable.

Bughunter no longer has OSX available due to power cycling limitations in the colo and OS hangs caused by other urls.

Loading these manually with windbg and continuing after the first chance exception showed crashes which !exploitable rated as: User mode DEP access violations are exploitable.

Comment 7

[Carsten Book [:Tomcat]]

(In reply to Boris Zbarsky (:bz) from comment #4)
> Is this Windows-only?  I can't seem to reproduce in a Mac beta build....

yeah so far this was windows only. Also working on mac coverage in general from my instance/mac systems but so far didn't crash

Gary, regarding comment #5 still crash :( https://crash-stats.mozilla.com/report/index/ef823e43-05a3-4a0d-a46d-3ffd52130719 on windows 7 working on getting a testcase

Comment 8

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

I retried using:

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013-07-24-mozilla-beta-debug/firefox-23.0.en-US.debug-win32.installer.exe

on Win7 with a new profile but was still unable to reproduce. Unable to help here!

Comment 9

[Lukas Blakk [:lsblakk] use ?needinfo]

Without reproducing it's not something we'd block release on, untracking.

Comment 10

[Carsten Book [:Tomcat]]

(In reply to Gary Kwong [:gkw] [:nth10sd] from comment #8)

Hey Gary.

Do you also Crash with a beta opt build? I never tried that beta debug so not sure. But i also was building a new build today (beta debug on my own) and still crash. I had to reload the page one time to get the crash.

So would be cool if you could try a opt build if thats possible :)

Comment 11

[Carsten Book [:Tomcat]]

also to add we see also different signatures on bughunter. 

On http://www.pebbleplace.com/Personal/Leica_db.html we crashed with js::GetElement see attached stack below also only on beta builds.

I tried to reproduce and also crashed during reloading of the page (if its not crashing on first try). Breakpad id was https://crash-stats.mozilla.com/report/index/84239f33-0b33-4af9-a206-881222130731

Comment 12

[Carsten Book [:Tomcat]]

Attachment: different stack

Comment 13

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

(In reply to Carsten Book [:Tomcat] from comment #10)
> Do you also Crash with a beta opt build?

No, see comment 5, where I mentioned I could not repro w/ 23.0b6 opt build downloaded off ftp.

Comment 14

[Andrew McCreight [:mccr8]]

Is this a dupe of bug 898832?  Same signature.

Comment 15

[Carsten Book [:Tomcat]]

(In reply to Andrew McCreight [:mccr8] from comment #14)
> Is this a dupe of bug 898832?  Same signature.

might be, bughunter is also seeing this a lot so this is really a real crash on real sites out in the web. cc'ing decoder maybe he can verify the testcase if this is related

Comment 16

[Carsten Book [:Tomcat]]

ok did a test again and this is somehow confusing

-> Firefox 23 Release (and the 23 beta 10 build) crash nearly on load of the testurl with

https://crash-stats.mozilla.com/report/index/e5d212f2-cef2-4653-b829-de30d2130809

(which kind of confirms its releated to bug 898332.

-> Firefox 24Beta1 Candidate -> no crash

this matches kinda with comment #0 where aurora and nightly builds were fine. So maybe whatever is fixing this is now uplifted from aurora to beta and so then protects the beta user

Comment 17

[Carsten Book [:Tomcat]]

(In reply to Carsten Book [:Tomcat] from comment #16)
> (which kind of confirms its releated to bug 898332.

Bug 898832 of course, sorry :)