1172189 - (CVE-2015-7175) Overflow in XULContentSinkImpl::AddText causes memory-safety bug

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[q1]

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);

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

XUL isn't exposed to the web so, this isn't as serious as bug 1172187.

Comment 2

[Andrew McCreight [:mccr8]]

Marking sec-other because it is not exposed to content.

Comment 3

[Andrea Marchesini [:baku]]

Attachment: crash8.patch

Comment 4

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/4c18b9c2c98c

Comment 5

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/4c18b9c2c98c

Is this worth backporting?

Comment 6

[Daniel Veditz [:dveditz]]

(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.

Comment 7

[Daniel Veditz [:dveditz]]

It can't hurt to backport if it's easy to do so, but I don't think it's necessary.

Comment 8

[Mike Hommey [:glandium]]

esr38 is still marked affected. Was it an oversight to not mark it wontfix, or to not land it on esr38?

Comment 9

[Al Billings [:abillings - ex-MoCo]]

(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.