Issue metadata
Sign in to add a comment
|
Stack-buffer-overflow in libGLESv2_swiftshader |
||||||||||||||||||||||
Issue descriptionDetailed report: https://clusterfuzz.com/testcase?key=6170593341997056 Fuzzer: inferno_layout_test_unmodified Job Type: windows_asan_chrome Platform Id: windows Crash Type: Stack-buffer-overflow READ {*} Crash Address: 0x00203d8f Crash State: libGLESv2_swiftshader libGLESv2_swiftshader libGLESv2_swiftshader Sanitizer: address (ASAN) Recommended Security Severity: Medium Regressed: https://clusterfuzz.com/revisions?job=windows_asan_chrome&range=464127:464504 Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=6170593341997056 Issue filed automatically. See https://dev.chromium.org/Home/chromium-security/bugs/reproducing-clusterfuzz-bugs for more information.
,
May 9 2017
This issue is a security regression. If you are not able to fix this quickly, please revert the change that introduced it. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 9 2017
,
May 9 2017
,
May 9 2017
SwiftShader dynamically generates functions, so ASAN may not be able to unwind the stack from within these functions, and certainly won't be able to symbolize anything. Especially on 32-bit Windows our stack layout is not very typical: https://chromium-review.googlesource.com/427348 So this might be a false positive.
,
May 9 2017
Hmm, ASan still detected the buffer overflow, regardless of the symbolization. Can you please try this locally?
,
May 9 2017
I'll certainly try this locally as soon as I get the chance, but I do think the symbolization is closely related to being able to correctly detect issues. For ASAN to know when the stack is overflowed, it needs to know the size of the stack frame, which it would know if it had all the symbols of the local variables or if it knew what stack layout is being used and it's a bounded one. But we're not producing debug information for the dynamically generated functions, and we're using a non-standard stack layout. So even if ASAN makes some guesses it most likely gets it wrong. I've learned not to underestimate ASAN, but this time I'd be deeply impressed if was working correctly. :)
,
May 10 2017
ClusterFuzz has detected this issue as fixed in range 470328:470348. Detailed report: https://clusterfuzz.com/testcase?key=6170593341997056 Fuzzer: inferno_layout_test_unmodified Job Type: windows_asan_chrome Platform Id: windows Crash Type: Stack-buffer-overflow READ {*} Crash Address: 0x00203d8f Crash State: libGLESv2_swiftshader libGLESv2_swiftshader libGLESv2_swiftshader Sanitizer: address (ASAN) Recommended Security Severity: Medium Regressed: https://clusterfuzz.com/revisions?job=windows_asan_chrome&range=464127:464504 Fixed: https://clusterfuzz.com/revisions?job=windows_asan_chrome&range=470328:470348 Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=6170593341997056 See https://dev.chromium.org/Home/chromium-security/bugs/reproducing-clusterfuzz-bugs for more information. If you suspect that the result above is incorrect, try re-doing that job on the test case report page.
,
May 10 2017
ClusterFuzz testcase 6170593341997056 is verified as fixed, so closing issue. If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.
,
May 10 2017
,
May 18 2017
,
Aug 16 2017
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
, May 9 2017