The FreeType Project - Bugs: bug #47114, Infinite loops in gray_render_line
You are not allowed to post comments on this tracker with your current authentication level.
bug #47114: Infinite loops in gray_render_line
Submitter: | None | ||
Submitted: | Thu 11 Feb 2016 04:01:26 AM UTC | ||
Severity: | 3 - Normal | Item Group: | Crash |
Status: | Confirmed | Privacy: | Public |
Assigned to: | podtelez | Open/Closed: | Open |
Planned Release: | 2.6.4 |
Jump to the original submission
Tue 15 Mar 2016 02:49:29 AM UTC, comment #31: |
Alexei Podtelezhnikov <podtelez> |
Mon 14 Mar 2016 06:50:54 PM UTC, comment #30: The 64-bit version does not reveal any bugs, but it does not
|
Kostya Serebryany <kcc> |
Sun 13 Mar 2016 11:35:46 AM UTC, comment #29: I can confirm this (it took me a while to compile FreeType in 32bit mode – my openSuSE box doesn't come with proper 32bit .pc files for pkgconfig, and it's a pain to compile HarfBuzz without them, so I disabled it).
|
Werner LEMBERG <wl> |
Sun 13 Mar 2016 12:22:46 AM UTC, comment #28: That's only on 32-bit, btw.
|
Kostya Serebryany <kcc> |
Sun 13 Mar 2016 12:11:44 AM UTC, comment #27: With the recent changes if first prints a bunch of int oevrflows,
|
Kostya Serebryany <kcc> |
Sat 12 Mar 2016 10:49:45 PM UTC, comment #26: Thanks for the explanations.
|
Werner LEMBERG <wl> |
Sat 12 Mar 2016 07:30:35 AM UTC, comment #25: (that's experimental coverage report, we are still trying to figure out the UI part).
|
Kostya Serebryany <kcc> |
Sat 12 Mar 2016 07:23:22 AM UTC, comment #24: Thanks. However, I have difficulties to understand the explanations.
|
Werner LEMBERG <wl> |
Fri 11 Mar 2016 12:09:09 AM UTC, comment #23: The fuzzer stops producing interesting coverage almost instantly,
|
Kostya Serebryany <kcc> |
Mon 07 Mar 2016 03:44:10 PM UTC, comment #22: There are plenty of dot and cross products to overflow even with the limited outline dimensions on 32-bit platforms. Please find those.
|
Alexei Podtelezhnikov <podtelez> |
Mon 07 Mar 2016 07:37:49 AM UTC, comment #21: Well, rasterfuzzer.cc needs to be expanded; maybe Alexei can work on this – it is intentionally very simple, without providing big code coverage. It was just meant as a starter to check the most serious overflows in both the B/W and gray rasterizer.
|
Werner LEMBERG <wl> |
Mon 07 Mar 2016 07:20:22 AM UTC, comment #20: From the first quick run the target looks boring -- the coverage stops growing almost instantly.
|
Kostya Serebryany <kcc> |
Mon 07 Mar 2016 06:46:11 AM UTC, comment #19: Looks good, thanks! With some quick tests, I wasn't able to trigger the sanitizer running `rasterfuzzer.cc'.
|
Werner LEMBERG <wl> |
Mon 07 Mar 2016 05:03:34 AM UTC, comment #18: Let's see how things improve after this commit. |
Alexei Podtelezhnikov <podtelez> |
Wed 02 Mar 2016 08:17:49 AM UTC, comment #17: Sounds reasonable. Will you have a look? |
Werner LEMBERG <wl> |
Tue 01 Mar 2016 02:51:32 PM UTC, comment #16: We have a realistic limit onthe bitmaps that we produce, which is 32767x32767 = 1Gb. So I suggest that we outright reject outlines that exceed ±2097088 (in 26.6 fixed point) in FT_Ouline_Get_Bitmap. We are talking about 16 inch letters on 2000 dpi printers. I think this is reasonable and should cover the bulk of the overflows. Perhaps there are other function that need this limit.
|
Alexei Podtelezhnikov <podtelez> |
Tue 01 Mar 2016 08:44:46 AM UTC, comment #15: Thanks for the input file. I've made it more C++ (please check!) and added it to the ftfuzzer directory in FreeType; it tests both the gray and mono rasterizers. Later on it should be refined, e.g., by constructing more than a single outline, having a larger target buffer, etc.
|
Werner LEMBERG <wl> |
Tue 01 Mar 2016 01:51:53 AM UTC, comment #14: I've made a quick-n-dirty fuzz target for FT_Outline_Get_Bitmap
|
Kostya Serebryany <kcc> |
Mon 29 Feb 2016 11:19:54 PM UTC, comment #13: And yes, I agree this is very good idea! |
Kostya Serebryany <kcc> |
Mon 29 Feb 2016 11:01:04 PM UTC, comment #12: You can go with a command line switch or with a separate file.
|
Kostya Serebryany <kcc> |
Sat 27 Feb 2016 09:38:01 AM UTC, comment #11: A very good idea IMHO! I wonder how this could be implemented: More code to `ftfuzzer.cc', to be controlled with command line switches? A separate `ftrenderfuzzer.cc' file?
|
Werner LEMBERG <wl> |
Thu 25 Feb 2016 01:58:04 PM UTC, comment #10: I wonder if this code can be used in the fuzzer, by-passing all the font parsing. This way we could potentially stress test both smooth and b/w rasterizer separately. Werner, please comment. |
Alexei Podtelezhnikov <podtelez> |
Wed 24 Feb 2016 12:19:13 AM UTC, comment #9: Attached is some C source that reproduces the infinite loop by calling FT_Outline_Get_Bitmap rather than an internal API.
|
David lattimore <dml> |
Tue 23 Feb 2016 10:25:35 PM UTC, comment #8: Skia bug report: https://bugs.chromium.org/p/skia/issues/detail?id=4998 |
David lattimore <dml> |
Tue 23 Feb 2016 03:36:38 AM UTC, comment #7: Thanks for that. I'm still investigating, but at this stage it looks like another integer overflow. This time in Skia. |
David lattimore <dml> |
Wed 17 Feb 2016 03:39:40 AM UTC, comment #6: See this commit. I am still curious to see what it takes to generate 56,000-point lines. Please provide the test case eventually. |
Alexei Podtelezhnikov <podtelez> |
Fri 12 Feb 2016 02:40:58 PM UTC, comment #5: Never mind. You have 64-bit long and 32-bit int, much like I do. |
Alexei Podtelezhnikov <podtelez> |
Fri 12 Feb 2016 02:24:57 PM UTC, comment #4: It is very possible that there are more than one bug in this report. I will make TArea unconditionally long, but still I am curious so please bear with me. To get int there, if PIXEL_BITS is 8, you must have UINT_MAX different from 0xFFFFU, i.e. you int is not 32 bits. Yet you say that it overflows and your long is 64 bits. What kind of environment is that?
|
Alexei Podtelezhnikov <podtelez> |
Fri 12 Feb 2016 12:02:46 AM UTC, comment #3: Sorry about the anonymous post. I didn't think to create an account until after I'd posted.
|
David lattimore <dml> |
Thu 11 Feb 2016 08:48:36 PM UTC, comment #2: The easy and correct solution is to just use long for TArea as suggested, because TPos and TCoord are not shy about it. I wonder why int was even considered for TArea.
|
Alexei Podtelezhnikov <podtelez> |
Thu 11 Feb 2016 06:20:59 AM UTC, comment #1: Alexei, please have a look! |
Werner LEMBERG <wl> |
Thu 11 Feb 2016 04:01:26 AM UTC, original submission:
The function gray_render_line can go into an infinite loop. I've observed this in a production system that is using FreeType. I've been somewhat restricted in the information I've been able to get from the core files where this has happened since gcc optimizes out most of the variables, so they don't show up in gdb. So I don't know what glyph it's trying to draw nor at what scale. I was however able to get some of the arguments that were passed to gray_render_line and was able to reproduce the problem by passing these same values.
|
Anonymous |
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 20 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2016-03-14 | kcc | Attached File | - | Added raster-cov-2.html, #36636 | |
2016-03-13 | wl | Status | Fixed | Confirmed | |
Open/Closed | Closed | Open | |||
Summary | Infinite loop in gray_render_line | Infinite loops in gray_render_line | |||
2016-03-11 | kcc | Attached File | - | Added raster-cov.html, #36600 | |
2016-03-07 | wl | Status | Confirmed | Fixed | |
Open/Closed | Open | Closed | |||
2016-03-01 | wl | Attached File | - | Added 2778 - embedded font without hmtx table.pdf, #36517 | |
Status | Fixed | Confirmed | |||
Open/Closed | Closed | Open | |||
2016-03-01 | kcc | Attached File | - | Added ft_overflow.c, #36516 | |
2016-02-25 | podtelez | Carbon-Copy | - | Added -email is unavailable- | |
2016-02-24 | dml | Attached File | - | Added ft_overflow.c, #36447 | |
2016-02-17 | podtelez | Status | None | Fixed | |
Open/Closed | Open | Closed | |||
Planned Release | None | 2.6.4 | |||
2016-02-11 | wl | Assigned to | None | podtelez | |
2016-02-11 | dml | Carbon-Copy | - | Added dml | |
2016-02-11 | dml | Carbon-Copy | Removed -email is unavailable- | - | |
2016-02-11 | dml | Carbon-Copy | - | Added -email is unavailable- |
Powered by Savane 3.13-cf05.
Corresponding source code
I've responsibly reverted to the old implementation until I fix the overflow on line 969.
My gut feeling is that you'll find lines 1239,1247,1255,1256 next. Let's see.