The default bug view has changed. See this FAQ.

Use deferred release for documents in nsHTMLDocumentSH::ReleaseDocument

RESOLVED FIXED in Firefox 14

Status

()

Core
DOM
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: billm, Assigned: mccr8)

Tracking

({sec-critical})

Trunk
mozilla16
sec-critical
Points:
---

Firefox Tracking Flags

(firefox13 wontfix, firefox14+ fixed, firefox15+ fixed, firefox16 fixed, firefox-esr1014+ fixed)

Details

(Whiteboard: [qa-][advisory-tracking+])

Attachments

(2 attachments)

(Reporter)

Description

5 years ago
There are a couple classes in nsDOMClassInfo.cpp that have a finalizer that calls the Release function on a document. We've had trouble with situations like this before, since the destructor can possible cause JS code to run. These calls should use deferred release.
Critsmash triage: marking this as sec-other to remove from untriaged list. Please have us re-rate if an exploitable bug is found or open more specific bugs for the issues as discovered.
Keywords: sec-other
We should treat this as sec-critical.
Keywords: sec-other → sec-critical
OK thanks Kyle. Assigning to Andrew (DOM sec contact) for further triage/assignment/fixage.
Assignee: nobody → continuation
(Assignee)

Comment 4

5 years ago
So basically what is needed here is to make sure that ReleaseDocument does something like XPC_WN_NoHelper_Finalize?  I'm also going to see what happens if I add an assertion that fails if the GC is running when we do ~nsDocument.  Hopefully that will catch this in a try run.

Speaking of XPC_WN_NoHelper_Finalize, is there some reason that it does a deferred release, but XPC_WN_Helper_Finalize doesn't defer it?  Or should I file a bug on that...
(Assignee)

Comment 5

5 years ago
Created attachment 624790 [details] [diff] [review]
don't let ~nsDocument run during a GC

When I browsed around a little, I didn't hit my assertion, but during shutdown I did end up in ~nsDocument during a GC.
(Reporter)

Comment 6

5 years ago
(In reply to Andrew McCreight [:mccr8] from comment #4)
> Speaking of XPC_WN_NoHelper_Finalize, is there some reason that it does a
> deferred release, but XPC_WN_Helper_Finalize doesn't defer it?  Or should I
> file a bug on that...

Yeah, I think that one is broken too.
(In reply to Andrew McCreight [:mccr8] from comment #4)
> Speaking of XPC_WN_NoHelper_Finalize, is there some reason that it does a
> deferred release, but XPC_WN_Helper_Finalize doesn't defer it?  Or should I
> file a bug on that...

See bug 712448, comment 21. Please file a bug. I don't think we have any slim wrappers for a scriptable helper with a finalizer, but we should fix it.
(Assignee)

Comment 8

5 years ago
Olli already filed bug 714725 back in January.  I threw a patch together for it.
(Assignee)

Updated

5 years ago
OS: Linux → All
Hardware: x86_64 → All
Version: unspecified → Trunk
(Assignee)

Comment 9

5 years ago
Created attachment 625276 [details] [diff] [review]
actual patch
(Assignee)

Comment 10

5 years ago
Comment on attachment 625276 [details] [diff] [review]
actual patch

I don't know if somebody else should review the actual changes in nsDOMClassInfo.

I did a little tidying of JSBool for one function, but I can revert that and add a !! or something if that's better.
Attachment #625276 - Flags: review?(bobbyholley+bmo)
Comment on attachment 625276 [details] [diff] [review]
actual patch

Bouncing this patch to peter.
Attachment #625276 - Flags: review?(bobbyholley+bmo) → review?(peterv)
status-firefox-esr10: --- → affected
status-firefox13: --- → wontfix
status-firefox14: --- → affected
status-firefox15: --- → affected
tracking-firefox14: --- → +
tracking-firefox15: --- → +
PeterV, friendly ping for review. We don't like crit bugs :)
Comment on attachment 625276 [details] [diff] [review]
actual patch

This is ok because documents hold nsContentUtils alive (through nsLayoutStatics) and that keeps XPConnect alive.
Attachment #625276 - Flags: review?(peterv) → review+
(Assignee)

Comment 14

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/7d05bf4570bd
tracking-firefox-esr10: --- → ?
Target Milestone: --- → mozilla16
(Assignee)

Comment 15

5 years ago
https://hg.mozilla.org/mozilla-central/rev/7d05bf4570bd
Status: NEW → RESOLVED
Last Resolved: 5 years ago
status-firefox16: --- → fixed
Resolution: --- → FIXED
Is there a simple way to test this fix?
(Assignee)

Comment 17

5 years ago
No, this was just found by code inspection.
(Assignee)

Comment 18

5 years ago
Comment on attachment 625276 [details] [diff] [review]
actual patch

[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration:
User impact if declined: possible sg:crit in some circumstances
Fix Landed on Version: 16
Risk to taking this patch (and alternatives if risky): fairly low. could change how some documents are released a little bit.
String or UUID changes made by this patch: none

[Approval Request Comment]
Bug caused by (feature/regressing bug #): unknown, but it is pretty old.
Testing completed (on m-c, etc.): it has been on m-c for a few days.
Attachment #625276 - Flags: approval-mozilla-esr10?
Attachment #625276 - Flags: approval-mozilla-beta?
Attachment #625276 - Flags: approval-mozilla-aurora?
Comment on attachment 625276 [details] [diff] [review]
actual patch

[Triage Comment]
Approving this low-risk sg:crit for all branches.
Attachment #625276 - Flags: approval-mozilla-esr10?
Attachment #625276 - Flags: approval-mozilla-esr10+
Attachment #625276 - Flags: approval-mozilla-beta?
Attachment #625276 - Flags: approval-mozilla-beta+
Attachment #625276 - Flags: approval-mozilla-aurora?
Attachment #625276 - Flags: approval-mozilla-aurora+

Updated

5 years ago
tracking-firefox-esr10: ? → 14+
(Assignee)

Comment 20

5 years ago
https://hg.mozilla.org/releases/mozilla-aurora/rev/61c987f44572
https://hg.mozilla.org/releases/mozilla-beta/rev/439fdaa19343
status-firefox14: affected → fixed
status-firefox15: affected → fixed
(Assignee)

Comment 21

5 years ago
esr10 required some minor futzing around with the name of a function.

https://hg.mozilla.org/releases/mozilla-esr10/rev/21aa63b0f89f
status-firefox-esr10: affected → fixed
qa- as per comment 17. Please set to qa+ if there is something QA can do to verify this fix.
Whiteboard: [qa-]
Whiteboard: [qa-] → [qa-][advisory-tracking+]
Group: core-security
You need to log in before you can comment on or make changes to this bug.