I managed to hang a renderer with the 7zOCC91D270/sf_06f55fce03bbb0cb41878f65c46fb2fc.webp file in the Win64.rar file, but didn't see problems with the other files.

Hi,

checking with other physical systems not always the browser crach, but running the fuzzer on the new systems will discover a new file working.
the same seems for the virtual systems, some crash immediately others after zoomed the image

I am running multiple fuzzers trying to identify a common generic one for platform

I have attached 3 new example file, working on windows 7 yltimate x86 both physical and virtual system

these files works also on android, the first 2 cause the fail the second one I need to touch the screen 1 time before the crash happen
Android 6.0  chrome version: 55.0.2883.91 

Deleted: sf_0a5d4210759c586bfbd59a336e5cfc4a.webp 238 KB

	sf_0a5d4210759c586bfbd59a336e5cfc4a.webp 238 KB View Download

Deleted: sf_b87bb7875195c847a4f08d3ee054d565-20-0x751c845d.webp 238 KB

	sf_b87bb7875195c847a4f08d3ee054d565-20-0x751c845d.webp 238 KB View Download

Deleted: sf_17db42d0918629eeda715cb00040e12f-278-0x751c845d.webp 238 KB

	sf_17db42d0918629eeda715cb00040e12f-278-0x751c845d.webp 238 KB View Download

ClusterFuzz is analyzing your testcase. Developers can follow the progress at https://cluster-fuzz.appspot.com/testcase?key=6118278528499712

ClusterFuzz is analyzing your testcase. Developers can follow the progress at https://cluster-fuzz.appspot.com/testcase?key=4971166851923968

ClusterFuzz is analyzing your testcase. Developers can follow the progress at https://cluster-fuzz.appspot.com/testcase?key=6540276983398400

ClusterFuzz seems cannot reproduce all three test cases in #3. 
alanbugz@, could you provide stacktrace or crash ID?

hi,

I have run the test case attached on windows x86 ( it work also on windows x64, linux and android )

Crash ID e2a0a235-8414-4efe-91ec-a0332a8be88b

Crash ID 38ac7a6b-0f5c-4b5c-a186-baf3939ea8fd

Crash ID 3d1e1ed7-b3bb-4d70-891b-253a42824ee1

Crash ID e5a46c62-3c4d-4d04-bc51-be4e34912b09


I have attached also the the case file sf_... , the chrome_bug log ( run with debug option ) the windgb stack and the minidump saved. the full dump is 42Mb compressed let me know if you need it too

Deleted: sf_b87bb7875195c847a4f08d3ee054d565.webp 238 KB

	sf_b87bb7875195c847a4f08d3ee054d565.webp 238 KB View Download

Deleted: chrome_debug.log 14.3 KB

chrome_debug.log 14.3 KB View Download

Deleted: chrome.dmp 35.9 KB

chrome.dmp 35.9 KB Download

Deleted: windbg.txt 23.7 KB

windbg.txt 23.7 KB View Download

the automatic report  point to a tab issue but the behavior can be also total freeze chrome 

Hi, thanks again for attaching that information. You've provided the local crash IDs but we really need the server IDs to be useful. They should look something like 2d3b91a880000000 (no dashes between segments). 

Hi, the original machine is gone, after other tests chrome was not able to work anymore or open any page ( local or remote, the error was always "Aw, Snap!"  even for settings or anything else ) deleting the "user data" folder was not fixing the issue.

using the file above on a new machine windows 7 ultimate x86 the browser provide the follow crashes:

Crash ID 08997965-5ebc-4837-b532-4a070f5d2b51 (Server ID: bf1288b580000000)


hope helps

Regards,

Alan

I can't reproduce this, but assuming I have the right link from the last comment [1] it looks like an oom. I can check webp outside of chrome to see just how much impact the image might be having in this.

[1] https://crash.corp.google.com/browse?q=&ignore_case=false&enable_rewrite=true&omit_field_name=&omit_field_value=&omit_field_opt=&stbtiq=product:Chrome%20bf1288b580000000&reportid=bf1288b580000000&index=0

For the record, dwebp will fail as the file appears truncated based on the size reported in the riff header. If you pull the canvas width and height from the VP8X header (using WebPGetInfo / WebPGetFeatures) you'll see some large resolutions [1]. The OOM could be due to allocations outside libwebp or a combination of them as we attempt to incrementally decode the image. The image bitstream is limited to 16K x 16K, however.

[1]:
sf_0a5d4210759c586bfbd59a336e5cfc4a.webp
49277 x 10819

sf_17db42d0918629eeda715cb00040e12f-278-0x751c845d.webp
12413 x 10819

sf_b87bb7875195c847a4f08d3ee054d565-20-0x751c845d.webp
32381 x 10819

sf_b87bb7875195c847a4f08d3ee054d565.webp
32381 x 10819

Thanks jzern@, to be clear, is there any memory access problems in dwebp or is just running out of memory and crashing in the "normal way"?

dwebp never makes it past inspecting the file structure. Chrome's wrapper uses the sizes reported above in a call to setSize() which will cause an allocation at some point.
From disk we never make it past demuxing in calls to libwebp. I can try a slow path to verify the partial demux and decode both in chrome and dwebp to be sure there isn't another hidden issue. I'll add an update in the next couple of days, right now this looks like a case of normal behavior.

Assigning to jzern@ for further debugging.

Hitting the partial decode path in chrome behaves as expected: we progress until the end of file and fail due to incomplete data. The setSize() does provide the basis for large allocations external to the library, one being 2132512768 bytes. So this looks to be working as intended after an allocation failure.

My 2 cents: It seems to be calling base::TerminateBecauseOutOfMemory(size) at the end and raising an exception so it doesn't look like a vulnerability to me.

Marking this as working as intended.

This 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