Atom table crash triggered by DOM mutation events and unicode surrogates




10 years ago
2 months ago


(Reporter: bc, Assigned: jst)


(4 keywords)

1.9.0 Branch
Dependency tree / graph
Bug Flags:
blocking1.9.0.11 +
wanted1.9.0.x +
wanted1.8.1.x -

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [sg:critical?] post 1.8-branch, )



10 years ago
+++ This bug was initially created as a clone of Bug #395651 +++

Created an attachment (id=280323)
testcase (causes shutdown crash)

This still crashes 1.9.0 on shutdown on Mac and Windows at least. security sensitive since the original was sg:critical and !exploitable says:

Probably Exploitable - Data from Faulting Address controls Code Flow starting at xpcom_core!AtomTableClearEntry+0x2b

#0  0x00000001 in ?? ()
#1  0x002de388 in AtomTableClearEntry (table=0x3a6700, entry=0x153f4738) at /work/mozilla/builds/1.9.0/mozilla/xpcom/ds/nsAtomTable.cpp:325
#2  0x002c2a4c in PL_DHashTableFinish (table=0x3a6700) at pldhash.c:373
#3  0x002ddda8 in NS_PurgeAtomTable () at /work/mozilla/builds/1.9.0/mozilla/xpcom/ds/nsAtomTable.cpp:414
#4  0x002da5d6 in NS_ShutdownXPCOM_P (servMgr=0x0) at /work/mozilla/builds/1.9.0/mozilla/xpcom/build/nsXPComInit.cpp:841
#5  0x000bc051 in ScopedXPCOMStartup::~ScopedXPCOMStartup (this=0xbfffe7ac) at /work/mozilla/builds/1.9.0/mozilla/toolkit/xre/nsAppRunner.cpp:931
#6  0x000bc09f in ScopedXPCOMStartup::~ScopedXPCOMStartup (this=0xbfffe7ac) at /work/mozilla/builds/1.9.0/mozilla/toolkit/xre/nsAppRunner.cpp:934
#7  0x000c2e18 in XRE_main (argc=4, argv=0xbfffea1c, aAppData=0x60dad0) at /work/mozilla/builds/1.9.0/mozilla/toolkit/xre/nsAppRunner.cpp:3237
#8  0x000026d3 in main (argc=4, argv=0xbfffea1c) at /work/mozilla/builds/1.9.0/mozilla/browser/app/nsBrowserApp.cpp:158


10 years ago
Flags: blocking1.9.0.11?
This looks like the same crash as bug 395651 -- did we not actually fix it? Was it fixed and then something regressed it? (note this test is now checked into the testsuite -- bug 395651 comment 7)

Assigning to jst who fixed the old version. Feel free to farm it out, but with the test in the tree we're going to want a fix sooner than later.
Assignee: nobody → jst
Flags: wanted1.9.0.x+
Whiteboard: [sg:critical?]
May have to push this to (code-freeze for .11 is May 6) but would at least like this looked at given the checked in testcase.
Flags: blocking1.9.0.11? → blocking1.9.0.11+
Flags: blocking1.9.0.11+ → blocking1.9.0.12+
Johnny, we really don't want to lose this for 1.9.0. Can you investigate for
Transplanting the fix for bug 421576 fixes this and bug 490513.
Depends on: 421576
Flags: blocking1.9.0.12+ → blocking1.9.0.11+
Fixed on CVS trunk (for by landing of bug 421576, 2009-05-06 18:33 -0700.

Thanks to jst, jwalden, and dveditz for helping.
Last Resolved: 10 years ago
Keywords: fixed1.9.0.11
Resolution: --- → FIXED
Verified fixed with with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: Gecko/2009051111 GranParadiso/3.0.11pre (my own debug build). Verified crash
This doesn't crash using Firefox 2 and isn't wanted there.
Flags: wanted1.8.1.x-
Whiteboard: [sg:critical?] → [sg:critical?] post 1.8-branch
This was a regression from the branch port of bug 439206 (as, it seems, was bug 490513).  If you look at the patch there, it clearly addressed an incompleteness of the patch for bug 421576 -- which only landed on mozilla-central and was intentionally not backported to 190, introducing this [sg:critical?] bug.  Oops.  I filed bug 497204 to reorganize and consolidate this code, because if four different people can write and review incorrect patches for this code (particularly security-critical code like encoding/decoding code), it clearly needs it.

Well, at least we picked up another point on Acid3 in this snafu (the original reason I investigated why the fix worked, incidentally).
Keywords: regression
Group: core-security
Component: DOM → DOM: Core & HTML
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.