[Webkit-unassigned] [Bug 144809] New: Fix possible race condition in BitmapImage::cacheFrame()

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri May 8 13:10:04 PDT 2015


https://bugs.webkit.org/show_bug.cgi?id=144809

            Bug ID: 144809
           Summary: Fix possible race condition in
                    BitmapImage::cacheFrame()
    Classification: Unclassified
           Product: WebKit
           Version: 528+ (Nightly build)
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Images
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: sabouhallawa at apple.com

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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150508/af837186/attachment.html>


More information about the webkit-unassigned mailing list