Timeout in pdf_font_fuzzer |
||||||
Issue descriptionDetailed report: https://clusterfuzz.com/testcase?key=4640735617089536 Fuzzer: libFuzzer_pdf_font_fuzzer Job Type: libfuzzer_chrome_asan Platform Id: linux Crash Type: Timeout (exceeds 25 secs) Crash Address: Crash State: pdf_font_fuzzer Sanitizer: address (ASAN) Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=4640735617089536 Issue filed automatically. See https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reference.md for more information. Note: This crash might not be reproducible with the provided testcase. That said, for the past 14 days we've been seeing this crash frequently. If you are unable to reproduce this, please try a speculative fix based on the crash stacktrace in the report. The fix can be verified by looking at the crash statistics in the report, a day after the fix is deployed. We will auto-close the bug if the crash is not seen for 14 days.
,
Jan 31 2018
,
Jan 31 2018
,
Feb 12 2018
npm@ Gentle ping! Could you please take a look in to this issue? Thanks!
,
Feb 13 2018
Looks like the font manages to say it has tons of chars and FT_Load_Glyph is slow on them. This is a FreeType bug. I'll see if there is any indication of a recent regression.
,
Feb 13 2018
This is slow even at FreeType commit c8d8e15803b0881809b3e15309795f8705471c32 so not a recent regression. I'm surprised FreeType allows magically obtaining lots of characters from such a small file, and then takes it's time loading them. +drott@ and +bungeman@ any ideas on whether this should be reported upstream?
,
Feb 13 2018
Well, there's nothing wrong with a font stating that it has a big automatic char to glyph map and that all those chars point to the same glyph, then having that one glyph be quite complex. In this case that glyph has a quite interestingly constructed hinting program which probably goes into an infinite loop. This is the reason for teh FreeType compile time option TT_CONFIG_OPTION_MAX_RUNNABLE_OPCODES which makes infinite loops stop sooner. If re-building the FreeType used by the fuzzer with TT_CONFIG_OPTION_MAX_RUNNABLE_OPCODES set to something low makes this run a lot faster, then that would be the issue.
,
Feb 14 2018
You're right, lowering TT_CONFIG_OPTION_MAX_RUNNABLE_OPCODES to 10 makes the testcase run in under a second. However I'm unsure how to lower the value just for the fuzzer.
,
Feb 15 2018
I think there is some value in having the fuzzer hit loops or other forms of DOSing in the interpreter, perhaps we can lower the value but also crash or somehow tell the fuzzer that it has found something?
,
Feb 16 2018
Yes ideally we would somehow change the fuzzer to do something different in this case, the problem is that the FreeType used by the fuzzer is chromium's copy.
,
Feb 16 2018
Assigning all my PDF bugs to dsinclair@ for triaging. Will not be working on PDFium for a month.
,
Apr 17 2018
We are closing all ooms and timeouts that are unreproducible. We won't be filing such bugs in future. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by brajkumar@chromium.org
, Jan 31 2018Components: Internals>Plugins>PDF
Labels: -Pri-1 M-66 Test-Predator-Wrong CF-NeedsTriage Pri-2