Closed Bug 389694 Opened 17 years ago Closed 17 years ago

Crash [@ nsImageDocument::RestoreImage()] with DOMAttrModified on image document, clicking and removing window

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

x86
Windows XP
defect
Not set
critical

Tracking

()

VERIFIED FIXED

People

(Reporter: martijn.martijn, Assigned: smaug)

References

Details

(Keywords: crash, testcase, Whiteboard: [sg:dos?] looks like a null deref)

Crash Data

Attachments

(3 files)

Attached file testcase
See testcase, when clicking on the black image in the iframe, Mozilla crashes.
Also happens on branch, so marking security sensitive for now.

http://crash-stats.mozilla.com/report/index/d5efc47d-3b9c-11dc-b20b-001a4bd43e5c
0  	nsImageDocument::RestoreImage()
1 	nsImageDocument::RestoreImageTo(int,int)
2 	nsImageDocument::HandleEvent(nsIDOMEvent *)
3 	nsEventListenerManager::HandleEventSubType(nsListenerStruct *,nsIDOMEventListener *,nsIDOMEvent *,nsISupports *,unsigned int)
4 	nsEventListenerManager::HandleEvent(nsPresContext *,nsEvent *,nsIDOMEvent * *,nsISupports *,unsigned int,nsEventStatus *)
5 	nsEventTargetChainItem::HandleEvent(nsEventChainPostVisitor &,unsigned int)
6 	nsEventTargetChainItem::HandleEventTargetChain(nsEventChainPostVisitor &,unsigned int,nsDispatchingCallback *)
7 	nsEventDispatcher::Dispatch(nsISupports *,nsPresContext *,nsEvent *,nsIDOMEvent *,nsEventStatus *,nsDispatchingCallback *)
8 	PresShell::HandleEventInternal(nsEvent *,nsIView *,nsEventStatus *)
9 	PresShell::HandleEventWithTarget(nsEvent *,nsIFrame *,nsIContent *,nsEventStatus *)
Oops! The testcase is crashing directly now.
It is a null pointer crash what I get.
Er, no, I got the null pointer crash when I tested the testcase you sent to me.
The testcase here does cause a SSensitive crash.
Assignee: nobody → Olli.Pettay
Status: NEW → ASSIGNED
Attachment #274005 - Flags: superreview?(jst)
Attachment #274005 - Flags: review?(jst)
Blocks: 389681
Attachment #274005 - Flags: superreview?(jst)
Attachment #274005 - Flags: superreview+
Attachment #274005 - Flags: review?(jst)
Attachment #274005 - Flags: review+
Hmm, bug 389663 seems to be the same, in some part?
In part, except my patch caused the crash to trigger in normal situations.
Add a test at least for the null-deref, please, if it's not obvious how to get from that to the security-sensitive crash?
Flags: in-testsuite?
Severity: normal → critical
Because of bug 389663, I'll check in only the null-check fixes part of
the patch.
Attachment #274977 - Flags: approval1.9?
Comment on attachment 274977 [details] [diff] [review]
only null-deref fixes

a1.9=dbaron
Attachment #274977 - Flags: approval1.9? → approval1.9+
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Verified fixed, using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007080805 Minefield/3.0a8pre
Status: RESOLVED → VERIFIED
The 1.8 branch seems to be only the null deref crash, and bug 389663 seems to be post 1.8. Is there a more dangerous crash on the 1.8 branch that I'm not seeing?
Whiteboard: [sg:nse?] looks like a null deref
Group: core-security
Flags: wanted1.8.1.x+
Whiteboard: [sg:nse?] looks like a null deref → [sg:dos?] looks like a null deref
Crash Signature: [@ nsImageDocument::RestoreImage()]
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: