Security : SEGV on unknown address 0x601ffe000c90 in Skia filter
Reported by
sweetv...@gmail.com,
Apr 28 2017
|
||||||||||||||||||||||||
Issue descriptionVULNERABILITY DETAILS This bug is related to crbug.com/705008 Clusterfuzz said that this bug is fixed but It can be reproduced on latest filter_fuzz_stub. ./filter_fuzz_stub ./poc_segv.fil [0428/121114.949826:INFO:filter_fuzz_stub.cc(59)] Test case: ./poc_segv.fil [0428/121114.950304:INFO:filter_fuzz_stub.cc(36)] Valid stream detected. ASAN:DEADLYSIGNAL ================================================================= ==32101==ERROR: AddressSanitizer: SEGV on unknown address 0x601ffe000c90 (pc 0x00000083d182 bp 0x7fff7b2b9fd0 sp 0x7fff7b2b9fa0 T0) ==32101==The signal is caused by a READ memory access. #0 0x83d181 in unaligned_load<unsigned char, unsigned char> third_party/skia/src/jumper/SkJumper_misc.h:21:5 #1 0x83d181 in load<unsigned char, unsigned char> third_party/skia/src/jumper/SkJumper_stages.cpp:180 #2 0x83d181 in load_a8_k third_party/skia/src/jumper/SkJumper_stages.cpp:678 #3 0x83d181 in sk_load_a8 third_party/skia/src/jumper/SkJumper_stages.cpp:674 #4 0x8380b2 in sk_start_pipeline third_party/skia/src/jumper/SkJumper_stages.cpp:131:13 #5 0x837b89 in operator() third_party/skia/src/jumper/SkJumper.cpp:179:17 #6 0x837b89 in SkRasterPipeline::run(unsigned long, unsigned long) const third_party/skia/src/jumper/SkJumper.cpp:211 #7 0x7bca60 in vertline third_party/skia/src/core/SkScan_Hairline.cpp:30:18 #8 0x7bca60 in SkScan::HairLineRgn(SkPoint const*, int, SkRegion const*, SkBlitter*) third_party/skia/src/core/SkScan_Hairline.cpp:139 #9 0x7c4c26 in hair_quad third_party/skia/src/core/SkScan_Hairline.cpp:240:5 #10 0x7c4c26 in hairquad third_party/skia/src/core/SkScan_Hairline.cpp:288 #11 0x7c4c26 in void hair_path<(SkPaint::Cap)1>(SkPath const&, SkRasterClip const&, SkBlitter*, void (*)(SkPoint const*, int, SkRegion const*, SkBlitter*)) third_party/skia/src/core/SkScan_Hairline.cpp:557 #12 0x67e31a in SkDraw::drawDevPath(SkPath const&, SkPaint const&, bool, SkBlitter*, bool) const third_party/skia/src/core/SkDraw.cpp:1070:5 #13 0x67ef7b in SkDraw::drawPath(SkPath const&, SkPaint const&, SkMatrix const*, bool, bool, SkBlitter*) const third_party/skia/src/core/SkDraw.cpp:1163:11 #14 0xe4d77a in drawPath third_party/skia/src/core/SkDraw.h:60:15 #15 0xe4d77a in SkLayerRasterizer::onRasterize(SkPath const&, SkMatrix const&, SkIRect const*, SkMask*, SkMask::CreateMode) const third_party/skia/src/effects/SkLayerRasterizer.cpp:140 #16 0x75935a in SkRasterizer::rasterize(SkPath const&, SkMatrix const&, SkIRect const*, SkMaskFilter*, SkMask*, SkMask::CreateMode) const third_party/skia/src/core/SkRasterizer.cpp:33:18 #17 0x67eeca in SkDraw::drawPath(SkPath const&, SkPaint const&, SkMatrix const*, bool, bool, SkBlitter*) const third_party/skia/src/core/SkDraw.cpp:1148:37 #18 0x67c652 in drawPath third_party/skia/src/core/SkDraw.h:55:15 #19 0x67c652 in SkDraw::drawRect(SkRect const&, SkPaint const&, SkMatrix const*, SkRect const*) const third_party/skia/src/core/SkDraw.cpp:798 #20 0xc5bdeb in drawRect third_party/skia/src/core/SkDraw.h:41:15 #21 0xc5bdeb in SkBitmapDevice::drawRect(SkRect const&, SkPaint const&) third_party/skia/src/core/SkBitmapDevice.cpp:205 #22 0x56bf8a in SkCanvas::onDrawRect(SkRect const&, SkPaint const&) third_party/skia/src/core/SkCanvas.cpp:2047:27 #23 0xebef9b in SkPaintImageFilter::onFilterImage(SkSpecialImage*, SkImageFilter::Context const&, SkIPoint*) const third_party/skia/src/effects/SkPaintImageFilter.cpp:65:13 #24 0x69ad49 in SkImageFilter::filterImage(SkSpecialImage*, SkImageFilter::Context const&, SkIPoint*) const third_party/skia/src/core/SkImageFilter.cpp:216:40 #25 0xc5f1db in SkBitmapDevice::drawSpecial(SkSpecialImage*, int, int, SkPaint const&) third_party/skia/src/core/SkBitmapDevice.cpp:406:49 #26 0x55ce24 in SkCanvas::internalDrawDevice(SkBaseDevice*, int, int, SkPaint const*) third_party/skia/src/core/SkCanvas.cpp:1330:25 #27 0x5589c1 in SkCanvas::internalRestore() third_party/skia/src/core/SkCanvas.cpp:1221:19 #28 0x5752d9 in ~AutoDrawLooper third_party/skia/src/core/SkCanvas.cpp:506:22 #29 0x5752d9 in SkCanvas::onDrawBitmap(SkBitmap const&, float, float, SkPaint const*) third_party/skia/src/core/SkCanvas.cpp:2331 #30 0x4f81d3 in RunTestCase skia/tools/filter_fuzz_stub/filter_fuzz_stub.cc:46:13 #31 0x4f81d3 in ReadAndRunTestCase skia/tools/filter_fuzz_stub/filter_fuzz_stub.cc:65 #32 0x4f81d3 in main skia/tools/filter_fuzz_stub/filter_fuzz_stub.cc:84 #33 0x7f1bc9a6382f in __libc_start_main /build/glibc-9tT8Do/glibc-2.23/csu/../csu/libc-start.c:291 AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV third_party/skia/src/jumper/SkJumper_misc.h:21:5 in unaligned_load<unsigned char, unsigned char> ==32101==ABORTING VERSION Chrome Version: asan-linux-release-467762 Operating System: - Ubuntu 16.04.1 LTS 64bit (Server) - Linux ubuntu 4.4.0-65-generic #86-Ubuntu SMP Thu Feb 23 17:49:58 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux REPRODUCTION CASE ./filter_fuzz_stub ./poc_segv.fil
,
Apr 28 2017
The top of the stack looks like very recent code.
,
Apr 29 2017
,
Apr 29 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 1 2017
Over to Mike for a look since this goes a little ways into Jumper code...
,
May 1 2017
Does this build configuration answer true to __has_feature(memory_sanitizer)? I see it says ASAN all over the place, but it's pretty unusual for an x86-64 machine to take this particular path unless it's using MSAN. (You'd see _sse2, _sse41, _avx, or _hsw suffixes on the various sk_foo() functions normally, and they'd be from SkJumper_generated.S.) Come to think of it, I may never have explicitly profiled an ASAN, but reading the code in SkJumper.cpp I'd think it'd just use the uninstrumented assembly normally. That said, this particular unusual path is sort of the trivial case where there are unlikely to be serious bugs inside SkJumper. That a8 load ends up as simple as *(*(const uint8_t** ptr)). If we're getting all the way down to unaligned_load(), the const uint8_t** has been dereferenced and is likely correct, and it's a problem with the underlying const uint8_t*. This is probably a geometric issue higher up in the pipeline, somewhere in the #7-#11 range, or maybe higher still? I suspect that this is not new per se, just newly going down this path. Same distal bug, new proximal segfault?
,
May 5 2017
ClusterFuzz is analyzing your testcase. Developers can follow the progress at https://cluster-fuzz.appspot.com/testcase?key=6364378508296192
,
May 5 2017
ClusterFuzz is analyzing your testcase. Developers can follow the progress at https://cluster-fuzz.appspot.com/testcase?key=6340766925586432
,
May 5 2017
ClusterFuzz is analyzing your testcase. Developers can follow the progress at https://cluster-fuzz.appspot.com/testcase?key=5294513160716288
,
May 5 2017
Regarding c#6, it does not crash on MSAN, only on ASAN 64-bit and 32-bit builds, see c#7, c#8, c#9 testcases.
,
May 6 2017
Ah, good, I got myself confused. If the crash is under SkJumper.cpp:211, it's expected to be in the serial code. Must be a machine that doesn't support AVX...
,
May 18 2017
If this is happening in the hairline (or earlier) setup code, very unlikely a regression. Removing RB label, reassign to reed@, potentially with help from mtklein@
,
May 19 2017
reed: Uh oh! This issue still open and hasn't been updated in the last 21 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers? If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one? If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started. Thanks for your time! To disable nags, add the Disable-Nags label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 19 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 19 2017
man vs machine
,
May 20 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 22 2017
,
May 23 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 23 2017
,
May 23 2017
,
May 24 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 25 2017
,
Jun 6 2017
,
Jul 6 2017
ClusterFuzz testcase 5294513160716288 is flaky and no longer reproduces, so closing issue. If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.
,
Oct 13 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
,
Jan 22 2018
|
||||||||||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||||||||||
Comment 1 by ClusterFuzz
, Apr 28 2017