Bug 144809 – Fix possible race condition in BitmapImage::cacheFrame()

• Status: RESOLVED
• Resolution: INVALID
• Component: Images

[Said Abou-Hallawa]

In BitmapImage::cacheFrame(), we should check the frame metadata loading status before, asking the image source to provide information about its metadata. A crash was reported on iOS with the following call stack:

CGImageSourceCopyPropertiesAtIndex()
WebCore::ImageSource::frameDurationAtIndex(unsigned long)
WebCore::BitmapImage::cacheFrameInfo(unsigned long)

The crash happens in CGImageSourceCopyPropertiesAtIndex() when it is called from ImageSource::frameDurationAtIndex(). But before BitmapImage::cacheFrameInfo() calls ImageSource::frameDurationAtIndex(), it calls ImageSource::orientationAtIndex() which calls CGImageSourceCopyPropertiesAtIndex() with exactly the same parameters. Two possible scenarios may have happened here:

1) The frame metadata was not complete when CGImageSourceCopyPropertiesAtIndex() was called the first time so it returns null and we fall back to the default value case in ImageSource::orientationAtIndex(). But in the second time, the image metadata loading was in progress but not complete, so we end up reading from still not allocated memory buffer.
2) The frame metadata was complete when CGImageSourceCopyPropertiesAtIndex() was called the first time but the frame itself was freed when the second call was made, so end up reading from a freed memory block.

[Said Abou-Hallawa]

Created attachment 252738 [details]
Patch

[Said Abou-Hallawa]

Created attachment 252741 [details]
Patch

[Said Abou-Hallawa]

Created attachment 252749 [details]
Patch

[Said Abou-Hallawa]

The crash I suspected to be the result of this race condition has been fixed in one of the MacOS/iOS components. So this is not an issue anymore.