Closed
Bug 529087
Opened 15 years ago
Closed 14 years ago
Crash [@ nsXBLBinding::AllowScripts]
Categories
(Core :: XBL, defect)
Core
XBL
Tracking
()
People
(Reporter: MatsPalmgren_bugz, Assigned: sicking)
References
Details
(Keywords: crash, Whiteboard: [sg:critical?][ccbr][critsmash:patch] [qa-needs-str])
Crash Data
Attachments
(1 file)
1.92 KB,
patch
|
smaug
:
review+
dveditz
:
approval1.9.2.7+
dveditz
:
approval1.9.1.11+
|
Details | Diff | Splinter Review |
It's ranked #276 in the 3.5.5 (past 7 days) top crash list:
http://crash-stats.mozilla.com/topcrasher/byversion/Firefox/3.5.5/7
with 389 crashes, 380 on Win, 9 on OSX.
stack:
nsXBLBinding::AllowScripts content/xbl/src/nsXBLBinding.cpp:1380
nsXBLBinding::ExecuteAttachedHandler content/xbl/src/nsXBLBinding.cpp:977
nsXBLBinding::ExecuteAttachedHandler content/xbl/src/nsXBLBinding.cpp:975
nsRunnableMethod<nsFileUploadContentStream>::Run xpcom/nsThreadUtils.h:278
nsContentUtils::RemoveScriptBlocker content/base/src/nsContentUtils.cpp:4344
PresShell::DoFlushPendingNotifications layout/base/nsPresShell.cpp:4842
PresShell::FlushPendingNotifications layout/base/nsPresShell.cpp:4798
nsDocument::FlushPendingNotifications content/base/src/nsDocument.cpp:6375
nsQueryReferent::operator nsWeakReference.cpp:88
nsComputedDOMStyle::GetPropertyCSSValue layout/style/nsComputedDOMStyle.cpp:349
xul.dll@0x8c4807
There are also 2 crashes on trunk within the past week, so it appears
the bug hasn't been fixed yet.
Comment 1•15 years ago
|
||
Line 1380 is:
1380 nsIDocument* doc = mBoundElement->GetOwnerDoc();
right?
Reporter | ||
Comment 2•15 years ago
|
||
Yes.
This crash might be what bug 307562 was about?
Comment 3•15 years ago
|
||
Hmm. mBoundElement is a weak ref, and is never unset, as far as I can tell. How's that supposed to work?
Group: core-security
Assignee | ||
Updated•15 years ago
|
blocking2.0: --- → beta1
Updated•15 years ago
|
Whiteboard: [sg:critical]
Updated•15 years ago
|
Whiteboard: [sg:critical] → [sg:critical?]
Updated•15 years ago
|
Assignee: nobody → jonas
Updated•15 years ago
|
Whiteboard: [sg:critical?] → [sg:critical?][ccbr]
Assignee | ||
Comment 4•15 years ago
|
||
Taking this. ETA end of next week.
Assignee | ||
Comment 5•15 years ago
|
||
I think this should do it.
Usually we're protected by the fact that nodes are always UnbindFromTree'ed from their document before they die. And unbinding removes any xbl bindings.
However nodes with NODE_FORCE_XBL_BINDINGS set can have xbl bindings without being in a document, and thus can die while still having bindings.
The change in this patch to nsNodeUtils takes care of this. This should ensure that mBoundElement never becomes dangling. This should be enough to take care of the security issues here.
However we also need to deal with that we can get a null mBoundElement while running nested constructors. Otherwise we would crash with a nullpointer deref and still have the topcrash reported in comment 0. The change to nsXBLBinding should take care of that.
Attachment #441671 -
Flags: review?(bzbarsky)
Assignee | ||
Comment 6•15 years ago
|
||
I think I can come up with tests for this. Asking for review in the meantime though.
Updated•15 years ago
|
Attachment #441671 -
Attachment is patch: true
Attachment #441671 -
Attachment mime type: application/octet-stream → text/plain
Updated•15 years ago
|
Whiteboard: [sg:critical?][ccbr] → [sg:critical?][ccbr][critsmash:patch]
Assignee | ||
Updated•15 years ago
|
Attachment #441671 -
Flags: review?(bzbarsky) → review?(Olli.Pettay)
Comment 7•15 years ago
|
||
Olli, can you review this security bug fix?
Comment 8•15 years ago
|
||
Yes, I will later this week. Sorry for the delay.
Comment 9•15 years ago
|
||
Comment on attachment 441671 [details] [diff] [review]
Patch to fix
Ok, makes sense.
Though, if BindingManager() may return null, we should rename it to GetBindingManager().
In theory it may return null, but I think we need to change ownership back to what it used to be (so that we can have strong parent pointer - which is a different bug.).
Attachment #441671 -
Flags: review?(Olli.Pettay) → review+
Assignee | ||
Comment 10•15 years ago
|
||
I think it can only return null during cycle collection. But yes, ideally we should improve the situation there.
Comment 11•15 years ago
|
||
Can we get this landed?
Comment 12•15 years ago
|
||
Security bugs need also sr.
Updated•15 years ago
|
Attachment #441671 -
Flags: superreview?(peterv)
Comment 13•15 years ago
|
||
Comment on attachment 441671 [details] [diff] [review]
Patch to fix
Or if peterv is away for some time, perhaps jst could sr.
Attachment #441671 -
Flags: superreview?(peterv) → superreview?(jst)
Reporter | ||
Comment 14•15 years ago
|
||
> Security bugs need also sr.
Not anymore. That rule was removed from the policy.
http://www.mozilla.org/hacking/reviewers.html
(the policy change was announced in mozilla.governance)
Comment 15•15 years ago
|
||
Comment on attachment 441671 [details] [diff] [review]
Patch to fix
Huh, we're changing rules faster than people learn them.
Attachment #441671 -
Flags: superreview?(jst)
Comment 16•14 years ago
|
||
Can we land this?
Assignee | ||
Comment 17•14 years ago
|
||
Checked in. Thanks for the review!
http://hg.mozilla.org/mozilla-central/rev/60fda31d4012
blocking1.9.1: --- → ?
blocking1.9.2: --- → ?
Assignee | ||
Updated•14 years ago
|
Attachment #441671 -
Flags: approval1.9.2.5?
Attachment #441671 -
Flags: approval1.9.1.11?
Assignee | ||
Comment 18•14 years ago
|
||
Hrm.. also checked in bustage fix due to merge.
http://hg.mozilla.org/mozilla-central/rev/adf3e43ffdd9
Comment 19•14 years ago
|
||
This should be marked fixed now, no?
Assignee | ||
Comment 20•14 years ago
|
||
Indeed! Somehow missed that in all the flag-setting.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Updated•14 years ago
|
Comment 21•14 years ago
|
||
Comment on attachment 441671 [details] [diff] [review]
Patch to fix
Approved for 1.9.2.5 and 1.9.1.11, a=dveditz for release-drivers
Attachment #441671 -
Flags: approval1.9.2.5?
Attachment #441671 -
Flags: approval1.9.2.5+
Attachment #441671 -
Flags: approval1.9.1.11?
Attachment #441671 -
Flags: approval1.9.1.11+
Updated•14 years ago
|
blocking1.9.2: .5+ → .6+
Updated•14 years ago
|
Attachment #441671 -
Flags: approval1.9.2.5+ → approval1.9.2.6+
Assignee | ||
Comment 23•14 years ago
|
||
Comment 24•14 years ago
|
||
Are there STR that can be used for verification of this fix on 1.9.1 and 1.9.2?
Whiteboard: [sg:critical?][ccbr][critsmash:patch] → [sg:critical?][ccbr][critsmash:patch] [qa-needs-str]
Comment 25•14 years ago
|
||
Jonas? Mats? Any reply?
Updated•14 years ago
|
Group: core-security
Updated•13 years ago
|
Crash Signature: [@ nsXBLBinding::AllowScripts]
You need to log in
before you can comment on or make changes to this bug.
Description
•