Issue metadata
Sign in to add a comment
|
Issue 54500: Renderer crash on very big animated gif image @ WebCore::RGBA32Buffer::setRGBA(unsigned int *,unsigned int,unsigned int,unsigned int,unsigned int)
Reported by
simon.sc...@gmail.com,
Sep 4 2010
|
||||||||||||||||||||||
Issue descriptionChrome Version : 7.0.503.1 (Official Build 57041) dev URLs (if applicable) : http://asset.soup.io/asset/1056/8367_7835_48-square.gif backup: http://home.arcor.de/slxviper/8367_7835_48-square.gif Other browsers tested: Add OK or FAIL after other browsers where you have tested this issue: Safari 4: Firefox 3.x: FAIL/(ok) IE 7: IE 8: (ok) What steps will reproduce the problem? 1. open above url (animated gif image, actual size 10176x7632 px) 2. observe RAM consumption What is the expected result? Image is displayed, browser and OS are continuing to work normally. OR: Warning is displayed, allocation of even more RAM is stopped. What happens instead? Huge amounts of RAM are consumed, until... a) on Windows: some RAM is allocated, "sad tab" is displayed, RAM is freed again b) on Linux: all available RAM ist allocated, everything hangs until killing that chrome process (which isn't that easy in this situation...) Please provide any additional information below. Attach a screenshot if possible. IE8 consumes about 110MB overall, FF 3.6.8 on Linux crashes as well, FF 3.6 on Windows needs about 360MB overall. Some image viewers crash as well. This bug was reported to soup.io as well, since the image should be only 48x48 px, so there seems to be a bug on their side as well. , Sep 7 2010
, Sep 24 2010
This one is easy (and not a regression); filed upstream as https://bugs.webkit.org/show_bug.cgi?id=46437 , to be patched shortly. , Sep 28 2010
Fixed upstream in http://trac.webkit.org/changeset/68446 , Sep 28 2010
Upon analysis, this is a security bug. We'll merge it to M7. Although the pointer written to is always based on NULL, the attacker can write to semi-arbitrary offsets by using a frame that has a non-zero x,y offset into the destination canvas. , Oct 1 2010
, Oct 4 2010
Merged in r69027 to 517. , Oct 14 2010
@sixviper: thanks for your help finding this. I'll credit you in our release notes as "sixviper", unless you wanted to give a different name? , Oct 14 2010Thanks for the credit. You could use my full name, Simon Schaak, for the release notes. , Oct 15 2010
@slxviper: congratulations! Your report was very useful and enabled us to correct a security bug. Therefore, you've qualified for a provisional $500 under the Chromium Security Rewards program. ---- Boilerplate text: please do NOT publicly disclose details until a fix has been released to all our users. Public disclosure may cancel the provisional reward. ---- , Oct 16 2010Nice to hear, I accecpt. Please contact me by (google)mail for further information. , Oct 17 2010
, Nov 3 2010
, Nov 21 2010
Payment is in the electronic system. , Mar 19 2011
Chrome Version : 7.0.503.1 (Official Build 57041) dev URLs (if applicable) : http://asset.soup.io/asset/1056/8367_7835_48-square.gif backup: http://home.arcor.de/slxviper/8367_7835_48-square.gif Other browsers tested: Add OK or FAIL after other browsers where you have tested this issue: Safari 4: Firefox 3.x: FAIL/(ok) IE 7: IE 8: (ok) What steps will reproduce the problem? 1. open above url (animated gif image, actual size 10176x7632 px) 2. observe RAM consumption What is the expected result? Image is displayed, browser and OS are continuing to work normally. OR: Warning is displayed, allocation of even more RAM is stopped. What happens instead? Huge amounts of RAM are consumed, until... a) on Windows: some RAM is allocated, "sad tab" is displayed, RAM is freed again b) on Linux: all available RAM ist allocated, everything hangs until killing that chrome process (which isn't that easy in this situation...) Please provide any additional information below. Attach a screenshot if possible. IE8 consumes about 110MB overall, FF 3.6.8 on Linux crashes as well, FF 3.6 on Windows needs about 360MB overall. Some image viewers crash as well. This bug was reported to soup.io as well, since the image should be only 48x48 px, so there seems to be a bug on their side as well. , Mar 21 2011
, Oct 5 2011
Batch update. , Oct 13 2012Project Member
This issue has been closed for some time. No one will pay attention to new comments. If you are seeing this bug or have new data, please click New Issue to start a new bug. , Mar 10 2013Project Member
, Mar 13 2013Project Member
, Mar 21 2013Project Member
, Mar 21 2013Project Member
, Apr 6 2013Project Member
, Oct 1 2016Project MemberThis bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot , Oct 2 2016Project MemberThis bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot , Oct 2 2016
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by sunandt@chromium.org, Sep 7 2010
Status: Untriaged
Summary: Renderer crash on very big animated gif image @ WebCore::RGBA32Buffer::setRGBA(unsigned int *,unsigned int,unsigned int,unsigned int,unsigned int)