Issue metadata
Sign in to add a comment
|
Integer-overflow in sw::FrameBufferX11::FrameBufferX11 |
||||||||||||||||||||||
Issue descriptionDetailed report: https://clusterfuzz.com/testcase?key=5986304278659072 Fuzzer: tokenfuzz_pdf_april16 Job Type: linux_ubsan_chrome Platform Id: linux Crash Type: Integer-overflow Crash Address: Crash State: sw::FrameBufferX11::FrameBufferX11 createFrameBuffer egl::WindowSurface::reset Sanitizer: undefined (UBSAN) Regressed: https://clusterfuzz.com/revisions?job=linux_ubsan_chrome&range=463874:463908 Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5986304278659072 Additional requirements: Requires Gestures Issue filed automatically. See https://github.com/google/clusterfuzz-tools for more information.
,
Jan 30 2018
Testcase 5986304278659072 is a top crash on ClusterFuzz for linux platform. Please prioritize fixing this crash. Marking this crash as a Beta release blocker. If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.
,
Jan 30 2018
This issue is marked as RB-Beta, hence assigning to Internals>GPU>SwiftShader dev for for more updates on this issue. Thanks!
,
Jan 30 2018
M65 Beta promotion is coming soon and your bug is labelled as Beta ReleaseBlock, pls make sure to land the fix and request a merge to M65 branch 3325 ASAP (merge has to be done latest by this Friday, 02/02 @ 5:00 PM PT). Thank you.
,
Jan 31 2018
I was unable to reproduce this, both with a local build and with --build download. The testcase is using gestures, and it indicates that this makes it inherently flaky. The integer overflow itself happens in the "x_image->bytes_per_line * x_image->height" calculation, where x_image is an X11 image created with XShmCreateImage(). So basically the image is too large to fit 4 GiB. It's not clear from the report if an image that large is actually being requested. If it is, then some layer above SwiftShader should prevent that from happening. Note that SwiftShader is a garbage-in-garbage-out implementation of OpenGL ES, just like many if not all other graphics drivers, and a humongous frame buffer is unreasonable in any situation. It's also possible that the image being requested isn't actually huge but instead the XShmCreateImage() call failed and we're trying to use the invalid output. Since this call is essential to the functioning of SwiftShader, it most probably means we can't recover from an error anyway. We could fail more gracefully, but without knowing the reason for the X11 failure that's not really helpful. It's hard to tell without being able to reproduce this issue. Note that it might depend on the X11 server that's being used. Also note that the regression revision range doesn't contain any SwiftShader commits. Either way I don't think there's anything actionable for SwiftShader here. And I'm not sure it should be a release blocker given the difficulty to repro. The worst case is that the GPU process crashes, and this is already a well handled scenario.
,
Feb 2 2018
Removing the ReleaseBlock flag. We're not seeing any crashes on our supported platforms, so this is likely specific to the clusterfuzz system setup.
,
Feb 5 2018
@capn: this bug is a top crasher for ClusterFuzz, which means it's blocking further fuzzing. Is there a way we could try to investigate some more, e.g. adding checks or something?
,
Feb 6 2018
Now ClusterFuzz can no longer reproduce it either. It would be great to know what went wrong so we can detect the issue earlier. Unfortunately I don't quite have the time to look into it any deeper. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by ClusterFuzz
, Jan 30 2018Labels: Test-Predator-Auto-Components