Use-of-uninitialized-value in transform_scanline_bgrA |
||||||||||||||||
Issue descriptionDetailed report: https://clusterfuzz.com/testcase?key=4868828111306752 Fuzzer: inferno_layout_test_unmodified Job Type: linux_msan_chrome Platform Id: linux Crash Type: Use-of-uninitialized-value Crash Address: Crash State: transform_scanline_bgrA SkPngEncoder::onEncodeRows SkEncoder::encodeRows Sanitizer: memory (MSAN) Recommended Security Severity: Low Regressed: https://clusterfuzz.com/revisions?job=linux_msan_chrome&range=534293:534294 Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=4868828111306752 Additional requirements: Requires Gestures Issue filed automatically. See https://github.com/google/clusterfuzz-tools for more information.
,
Feb 14 2018
,
Feb 14 2018
,
Feb 14 2018
,
Feb 15 2018
I have not debugged this, but this code is just reading from the SkPixmap passed in, leading me to believe that the SkPixmap is uninitialized. Adding liyuqian@, who plumbed this in, but I think the problem is before coming into Skia's encoder.
,
Feb 15 2018
,
Feb 15 2018
,
Mar 12 2018
,
Mar 13 2018
It's not clear that this is an issue with Skia. The blamelist only includes one Skia change which obviously did not change behavior: https://skia.googlesource.com/skia/+log/156562f37d197bdacfd47ece4b3ee6e5afc4ade1..d2807d5115ad0f6954fa0d77e761db5afdb38d68?pretty=fuller&n=10000 I suspect that the pixels being encoded are uninitialized. Unfortunately, this report does not include the allocation that created the uninitialized memory. (Some other reports do, e.g. https://oss-fuzz.com/v2/testcase-detail/5066764724469760?noredirect=1 . I don't know why this one is different.) This is not reproducible, so I don't think there's any way for us to verify.
,
Mar 19 2018
Automatically applying components based on crash stacktrace and information from OWNERS files. If this is incorrect, please apply the Test-Predator-Wrong-Components label.
,
Mar 19 2018
Reopening, since clusterfuzz just filed another one ( issue 822595 ). As I said there, I think the Skia code looks okay. zakerinasab@, I see you have touched ImageDataBuffer. Do you know if there might be a problem in ImageDataBuffer? (Or do you know who might know more?) I'm wondering if it's possible that the SkPixmap has uninitialized memory.
,
Mar 22 2018
,
Mar 22 2018
> Looking at this. Would you please add me to crbug.com/822595 ? Done, thanks!
,
Mar 22 2018
I tried both cluster fuzz test cases on a MSAN build of ToT, running multiple times. I was not able to reproduce the problem. Then I traced the code inside ImageDataBuffer to see where the pixmap is obtained. The test case reported in this bug uses gpu textures and goes to the line that uses SkImage::makeNonTextureImage() to get a software version of the accelerated image. The test case reported in crbug.com/822595 always uses software images, and they are not lazy generated. Then SkImage::peekPixels() is used to get the pixmap and the pixmap is passed through to the SkEncoder. Considering that we check the validity of the SkImage and SkPixmap in each step, if the problem is somewhere in Blink, I don't think it is in ImageDataBuffer code. I'll put some more time on this to see if I can find anything.
,
May 3 2018
zakerinasab - thanks for taking a stab at this. Feel free to un-assign if there's nothing to be found. Thanks!
,
May 7 2018
Still I can't reproduce. According to ClusterFuzz both test cases are flaky, so I suspect that there is not much to do here.
,
May 10 2018
,
Aug 17
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 |
||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||
Comment 1 by sheriffbot@chromium.org
, Feb 5 2018