Closed
Bug 610601
(CVE-2011-0061)
Opened 14 years ago
Closed 14 years ago
Firefox crash [@ ycc_rgb_convert] [@ ycc_rgb_convert_argb] on image with src set to a resource with multipart/x-mixed-replace content type [Access Violation]
Categories
(Core :: Graphics: ImageLib, defect)
Core
Graphics: ImageLib
Tracking
()
RESOLVED
FIXED
mozilla2.0b8
Tracking | Status | |
---|---|---|
status1.9.2 | --- | .14-fixed |
status1.9.1 | --- | unaffected |
People
(Reporter: jordi.chancel, Assigned: MatsPalmgren_bugz)
References
()
Details
(4 keywords, Whiteboard: [sg:critical?])
Crash Data
Attachments
(6 files, 2 obsolete files)
321 bytes,
text/html
|
Details | |
6.32 KB,
text/plain
|
Details | |
4.32 KB,
text/plain
|
Details | |
1.99 KB,
patch
|
joe
:
review+
joe
:
approval2.0+
|
Details | Diff | Splinter Review |
1.99 KB,
patch
|
dveditz
:
approval1.9.2.14+
|
Details | Diff | Splinter Review |
71.63 KB,
image/png
|
Details |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12
Visiting a webpage that contains an image with the src-attribute that refers to a multipart/x-mixed-replace resource , Firefox 3.6.12 crashes after some time.
Exactly the same as bug 524921
Tested on Windows 7
Reproducible: Always
Steps to Reproduce:
1. Visit test page
2. wait a few moments
Actual Results:
Firefox crashes
Expected Results:
Firefox don't crash
The crash is very intermittent , sometimes firefox will crash after some seconds , and sometimes firefox don't crash at all.
Reporter | ||
Comment 1•14 years ago
|
||
Reporter | ||
Comment 2•14 years ago
|
||
Assignee | ||
Comment 3•14 years ago
|
||
Assignee | ||
Comment 4•14 years ago
|
||
Assertions before the crash:
###!!! ASSERTION: number of restored image frames doesn't match the original number of frames!: 'num_expected_frames == mNumFrames', file /usr/moz/1.9.2/modules/libpr0n/src/imgContainer.cpp, line 1651
###!!! ASSERTION: ### nsCacheEntryHashTable::AddEntry - entry already used: '((nsCacheEntryHashTableEntry *)hashEntry)->cacheEntry == 0', file /usr/moz/1.9.2/netwerk/cache/src/nsCacheEntry.cpp, line 465
###!!! ASSERTION: ### Attempting to remove unknown cache entry!!!: 'check == cacheEntry', file /usr/moz/1.9.2/netwerk/cache/src/nsCacheEntry.cpp, line 484
Assignee | ||
Comment 5•14 years ago
|
||
Stack looks like bug 557107.
There's 4821 crashes in the past 2 week period:
http://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=contains&query=ycc_rgb_convert&date=11%2F09%2F2010%2002%3A24%3A27&range_value=2&range_unit=weeks&hang_type=any&process_type=any&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&admin=&signature=ycc_rgb_convert
It's #46 on the Firefox 3.6.11 top crash list.
Keywords: topcrash
Summary: Firefox crash on image with src set to a resource with multipart/x-mixed-replace content type [Access Violation] → Firefox crash [@ ycc_rgb_convert] [@ ycc_rgb_convert_argb] on image with src set to a resource with multipart/x-mixed-replace content type [Access Violation]
Comment 6•14 years ago
|
||
Anyone know if this is a branch only crash, or does it happen in 4.0 betas as well?
Assignee | ||
Comment 7•14 years ago
|
||
There are a few on 4.0b6 too, bp-12007da6-84d7-4f77-845d-fbd9a2101108
Comment 9•14 years ago
|
||
Mats, can you investigate here, or dupe as appropriate...
Assignee: nobody → matspal
Comment 10•14 years ago
|
||
> Visiting a webpage that contains an image with the src-attribute that
> refers to a multipart/x-mixed-replace resource , Firefox 3.6.12 crashes
> after some time.
>
> Exactly the same as bug 524921
multipart/x-mixed-replace is a red herring. That URL seems to return different (fuzzed?) jpeg images and some of them are tickling bug 557107, which we haven't had a testcase for. Some of the crashes are EXCEPTION_ACCESS_VIOLATION_WRITE so presumably exploitable. the crash reports point at
http://hg.mozilla.org/releases/mozilla-1.9.2/annotate/cd857b3b0e33/jpeg/jdcolor.c#l341
The area around the crashing line was changed as part of bug 411379, may not be part of upstream jpeg.
Changing the keyword from testcase to testcase-wanted because the important bit will be to capture one of the images that trigger the crash.
Updated•14 years ago
|
Keywords: testcase-wanted
Comment 11•14 years ago
|
||
Mats, ping?
Assignee | ||
Comment 12•14 years ago
|
||
Assignee | ||
Comment 13•14 years ago
|
||
The problem starts in the crash stack #4, nsJPEGDecoder::OutputScanlines:
http://hg.mozilla.org/mozilla-central/annotate/5ae1f2fa0d9f/modules/libpr0n/decoders/nsJPEGDecoder.cpp#l555
where 'mImageData' is NULL. I tracked this back to an earlier failure
in EnsureCleanFrame (see 2nd stack), where it tries to reuse a frame
that has no image data.
Assignee | ||
Comment 14•14 years ago
|
||
I don't know this code at all, but I think this should at least avoid the crash.
Attachment #494942 -
Flags: review?(bobbyholley+bmo)
Assignee | ||
Comment 15•14 years ago
|
||
Updated•14 years ago
|
Attachment #494942 -
Flags: review?(bobbyholley+bmo) → review?(joe)
Assignee | ||
Comment 16•14 years ago
|
||
It passed TryServer unit tests, builds are here:
http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/mpalmgren@mozilla.com-d734b25e8af8/
Comment 17•14 years ago
|
||
Comment on attachment 494942 [details] [diff] [review]
trunk fix
It's a bit difficult to imagine how this could happen; I guess if we optimized the surface of the JPEG image.
This is obviously safer, but I think we should also turn off optimizing surfaces in the multipart/x-mixed-replace case. It's ok if you file that as a followup bug and cc bholley and me.
Attachment #494942 -
Flags: review?(joe) → review+
Assignee | ||
Comment 18•14 years ago
|
||
For the record, this is what 'frame' looked like when GetImageData()
returned the null image data:
$12 = {
mImageSurface = {
mRawPtr = 0x0
},
mOptSurface = {
mRawPtr = 0x7fffce946500
},
mSize = {
width = 640,
height = 480
},
mOffset = {
x = 0,
y = 0
},
mDecoded = {
x = 0,
y = 0,
width = 640,
height = 480
},
mPalettedImageData = 0x0,
mSinglePixelColor = {
r = 0,
g = 0,
b = 0,
a = 0
},
mTimeout = 100,
mDisposalMethod = 0,
mFormat = gfxASurface::ImageFormatRGB24,
mPaletteDepth = 0 '\000',
mBlendMethod = 1 '\001',
mSinglePixel = 0 '\000',
mNeverUseDeviceSurface = 0 '\000',
mFormatChanged = 0 '\000',
mCompositingFailed = 0 '\000'
}
Assignee | ||
Updated•14 years ago
|
Attachment #494942 -
Flags: approval2.0?
Assignee | ||
Updated•14 years ago
|
status1.9.1:
--- → unaffected
status1.9.2:
--- → ?
Comment 19•14 years ago
|
||
Ah, okay, so this was indeed an optimized image.
Updated•14 years ago
|
Attachment #494942 -
Flags: approval2.0? → approval2.0+
Assignee | ||
Comment 20•14 years ago
|
||
Status: NEW → RESOLVED
Closed: 14 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b8
Assignee | ||
Updated•14 years ago
|
Attachment #494943 -
Flags: approval1.9.2.14?
Comment 21•14 years ago
|
||
Comment on attachment 494943 [details] [diff] [review]
1.9.2 fix (same thing)
Approved for 1.9.2.14, a=dveditz for release-drivers
Attachment #494943 -
Flags: approval1.9.2.14? → approval1.9.2.14+
Comment 22•14 years ago
|
||
(In reply to comment #17)
> This is obviously safer, but I think we should also turn off optimizing
> surfaces in the multipart/x-mixed-replace case. It's ok if you file that as a
> followup bug and cc bholley and me.
Did the follow up bug happen?
Assignee | ||
Comment 23•14 years ago
|
||
Filed follow up bug 617651.
Assignee | ||
Comment 24•14 years ago
|
||
Comment 25•14 years ago
|
||
I haven't been able to replicate the crash on Windows or OS X using the test page pre-fix. Is there a more reliable way of inducing this crash?
Reporter | ||
Comment 26•14 years ago
|
||
The crash is very intermittent... but i've got a screenshot of one crash with with a line like 80 80 80 80 [...] before the access violation .
I think it's possible to localize this line on the JPG and maybe do a crash with evidence of corruption resulting in an overflow.
Reporter | ||
Comment 27•14 years ago
|
||
Comment 28•14 years ago
|
||
Jordi, what build and OS were you running this? Was this a post-fix 1.9.2 nightly build?
Reporter | ||
Comment 29•14 years ago
|
||
Tested on Windows Seven with Mozilla Firefox 3.6.13
Updated•14 years ago
|
Alias: CVE-2011-0061
Reporter | ||
Comment 30•14 years ago
|
||
the update was for today? =>https://wiki.mozilla.org/Releases
Assignee | ||
Comment 31•14 years ago
|
||
3.6.14 is delayed due to bug 633869.
Reporter | ||
Comment 32•14 years ago
|
||
Have you an idea of the release date?
Assignee | ||
Comment 33•14 years ago
|
||
Sorry, I don't know.
Reporter | ||
Updated•14 years ago
|
Attachment #489118 -
Attachment is obsolete: true
Reporter | ||
Updated•14 years ago
|
Attachment #502194 -
Attachment is obsolete: true
Reporter | ||
Comment 34•14 years ago
|
||
Reporter | ||
Comment 35•14 years ago
|
||
the fix release is for today isn't it? :)
Comment 36•14 years ago
|
||
Yes.
Assignee | ||
Comment 37•14 years ago
|
||
There are still some related issues with multipart/x-mixed-replace images
that I'm investigating in bug 638018. Please don't make this bug public
until that bug is.
Updated•14 years ago
|
Group: core-security
Updated•14 years ago
|
Crash Signature: [@ ycc_rgb_convert]
[@ ycc_rgb_convert_argb]
Updated•11 years ago
|
Crash Signature: [@ ycc_rgb_convert]
[@ ycc_rgb_convert_argb] → [@ ycc_rgb_convert]
[@ ycc_rgb_convert_argb]
Flags: sec-bounty+
Updated•9 years ago
|
Keywords: testcase-wanted
Updated•8 months ago
|
Keywords: reporter-external
You need to log in
before you can comment on or make changes to this bug.
Description
•