Closed Bug 1172189 (CVE-2015-7175) Opened 7 years ago Closed 7 years ago
Overflow in XULContent
Sink Impl::Add Text causes memory-safety bug
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:36.0) Gecko/20100101 Firefox/36.0 Build ID: 20150305021524 Steps to reproduce: This bug is just like https://bugzilla.mozilla.org/show_bug.cgi?id=1172187 , but in XULContentSinkImpl::AddText (38.0.1\dom\xul\nsXULContentSink.cpp), line 1075: 1075: mTextSize += aLength; 1076: mText = (char16_t *) moz_realloc(mText, sizeof(char16_t) * mTextSize);
Summary: XULContentSinkImpl::AddText causes memory-safety bug → Overflow in XULContentSinkImpl::AddText causes memory-safety bug
XUL isn't exposed to the web so, this isn't as serious as bug 1172187.
Marking sec-other because it is not exposed to content.
Assignee: nobody → amarchesini
Attachment #8621018 - Flags: review?(ehsan)
https://hg.mozilla.org/mozilla-central/rev/4c18b9c2c98c Is this worth backporting?
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla41
(In reply to Olli Pettay [:smaug] from comment #1) > XUL isn't exposed to the web so, this isn't as serious as bug 1172187. Not directly. We do, in some cases, take aspects of web content and display text in our own XUL dialogs. Seems super unlikely to be a problem if the text survived in in the HTML page but we can't rule it out, either.
It can't hurt to backport if it's easy to do so, but I don't think it's necessary.
Whiteboard: [post-critsmash-triage] → [post-critsmash-triage][adv-main41+]
esr38 is still marked affected. Was it an oversight to not mark it wontfix, or to not land it on esr38?
(In reply to Mike Hommey [:glandium] from comment #8) > esr38 is still marked affected. Was it an oversight to not mark it wontfix, > or to not land it on esr38? Sec-low bugs don't get checked into ESR branches without an overriding reason.
You need to log in before you can comment on or make changes to this bug.