Closed
Bug 851996
Opened 12 years ago
Closed 12 years ago
"Assertion failure: !aGCThing" re-initing event
Categories
(Core :: DOM: Events, defect)
Tracking
()
RESOLVED
FIXED
mozilla22
Tracking | Status | |
---|---|---|
firefox20 | --- | unaffected |
firefox21 | --- | unaffected |
firefox22 | --- | fixed |
firefox-esr17 | --- | unaffected |
b2g18 | --- | unaffected |
People
(Reporter: jruderman, Assigned: smaug)
References
Details
(4 keywords, Whiteboard: [adv-main22-])
Attachments
(3 files)
Assertion failure: !aGCThing, at js/xpconnect/src/XPCJSRuntime.cpp:319
Reporter | ||
Comment 1•12 years ago
|
||
Comment 2•12 years ago
|
||
This looks like something mccr8 would know about.
Comment 3•12 years ago
|
||
Yeah, I looked at the stacks a bit. It looks like the problem is that nsDOMMessageEvent::InitMessageEvent calls NS_DROP_JS_OBJECTS without clearing the wrapper cache first. I think this is a regression from bug 822399, which made nsDOMEvent wrapper cached.
Blocks: 822399
status-b2g18:
--- → unaffected
status-firefox20:
--- → unaffected
status-firefox21:
--- → unaffected
status-firefox22:
--- → affected
status-firefox-esr17:
--- → unaffected
Comment 4•12 years ago
|
||
Feel free to reassign to me, Olli.
Assignee: nobody → bugs
Keywords: csec-uaf,
sec-critical
Assignee | ||
Comment 5•12 years ago
|
||
nah, my bug.
Assignee | ||
Comment 6•12 years ago
|
||
Ok, I have the patch and comment for it:
"Good that I added the assertion.
So, this should work. If we already have preserved wrapper or object
hold, calling NS_HOLD_JS_OBJECTS doesn't really do anything (because the
event is already in JSHolders).
If we don't have preserved wrapper nor object hold, the event ends up to
JSholders. Then we may unlink mData, or if the last reference to the event
is released without cycle collector, event's dtor drops the reference."
But bugzilla is broken atm. Doesn't accept attachments.
Assignee | ||
Comment 7•12 years ago
|
||
Attachment #726124 -
Flags: review?(continuation)
Updated•12 years ago
|
Attachment #726124 -
Flags: review?(continuation) → review+
Assignee | ||
Comment 8•12 years ago
|
||
Comment on attachment 726124 [details] [diff] [review]
patch
I can't recall whether this thunk-only bug requires an approval.
[Security approval request comment]
How easily could an exploit be constructed based on the patch?
Crash is quite easy to find.
Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?
Comment will be about proper tracing
Which older supported branches are affected by this flaw?
None. This is a regression from bug 822399
How likely is this patch to cause regressions; how much testing does it need?
Not likely to cause regressions.
Attachment #726124 -
Flags: sec-approval?
Comment 9•12 years ago
|
||
Comment on attachment 726124 [details] [diff] [review]
patch
Trunk-only does not need sec-approval.
Attachment #726124 -
Flags: sec-approval?
Assignee | ||
Comment 10•12 years ago
|
||
Comment 11•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/ee2e53392df1
Can we land the test?
Status: NEW → RESOLVED
Closed: 12 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → mozilla22
Updated•11 years ago
|
Whiteboard: [adv-main22-]
Updated•11 years ago
|
Group: core-security
You need to log in
before you can comment on or make changes to this bug.
Description
•