bugThe FreeType Project - Bugs: bug #54019, A value overflows, resulting in a...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #54019: A value overflows, resulting in a large loop

Submitter:  lonely <flywrongsnow>
Submitted:  Thu 31 May 2018 06:36:20 AM UTC
   
 
Severity:  3 - Normal Item Group:  Incorrect behaviour
Status:  Fixed Privacy:  Public
Assigned to:  wl Open/Closed:  Closed
Planned Release:  2.10.0

Jump to the original submission

Sun 24 Jun 2018 08:01:42 PM UTC, comment #18: 

No specific reason – I simply updated the code.  Feel free to add a fallback matrix :-)

Werner LEMBERG <wl>
Group administrator
Sun 24 Jun 2018 05:30:59 PM UTC, comment #17: 

Thanks for picking up the slack! Is there any reason why you do not want to fall back on default in t1/t42/cid fonts? Do these fonts specify the upem through the font matrix only?

Alexei Podtelezhnikov <podtelez>
Group Member
Sun 24 Jun 2018 04:29:42 AM UTC, comment #16: 

I've now added an `FT_Check_Matrix' function to FreeType to find degenerate matrices.

Please test!

Werner LEMBERG <wl>
Group administrator
Wed 06 Jun 2018 09:37:32 PM UTC, comment #15: 


> I was thinking about rejecting degenerate transformations
> at some point too, xx*yy - xy*yx = 0.  Now that you mention
> extreme shear we might consider this as unacceptable
>
> 50 abs(xx*yy - xy*yx) <= xx*xx + xy*xy + yx*yx yy*yy

                                                   ^
                           I guess this should be `+' ...
 

> This rejects [0.001 0 1 0.001 0 0], but proper rotations
> survive.


Thanks.  Do you have any reference for this estimation?

> Still any value above 1 is suspicious.  What is the font
> matrix in the broken font?


It's

  [0.001 0 2147483647 0.001 0 0]    .

This causes overflow, and FreeType returns

  [0.001 0 32767 0.001 0 0]

instead.

Werner LEMBERG <wl>
Group administrator
Wed 06 Jun 2018 07:47:55 PM UTC, comment #14: 

I was thinking about rejecting degenerate transformations at some point too, xx*yy - xy*yx = 0. Now that you mention extreme shear we might consider this as unacceptable

50 abs(xx*yy - xy*yx) <= xx*xx + xy*xy + yx*yx yy*yy

This rejects [0.001 0 1 0.001 0 0], but proper rotations survive. Still any value above 1 is suspicious. What is the font matrix in the broken font?

Alexei Podtelezhnikov <podtelez>
Group Member
Wed 06 Jun 2018 03:35:21 PM UTC, comment #13: 

Hmm.  Do you think that, say,

  [0.001 0 1 0.001 0 0]

makes sense?  This is still a very extreme shearing of almost 90°...

What about saying that the ratio of any combinations of xy and yx with xx and yy must not exceed factor 50?  arctan 50 is still approx. 88°.

Are you aware of a simple algorithm to compute a `distortion' measure?

Werner LEMBERG <wl>
Group administrator
Wed 06 Jun 2018 02:57:53 PM UTC, comment #12: 

The typical font matrix [0.001 0 0 0.001 0 0] scales font units down to Em units. I would say that scaling up here is not very practical. I think we should should fall back on the default matrix anytime we see values exceeding 1 in the first four elements.

Alexei Podtelezhnikov <podtelez>
Group Member
Wed 06 Jun 2018 06:23:58 AM UTC, comment #11: 

Thanks for the timings.  I wasn't aware that JPEG is limited to a maximum size of 0xFFFF×0xFFFF – I've now added guards to both the gray and B/W rasterizer.

Any suggestions what heuristic limits we should apply to catch malformed font matrix values of PS-flavoured fonts?

Werner LEMBERG <wl>
Group administrator
Tue 05 Jun 2018 07:12:12 PM UTC, comment #10: 

I dunno. Here is the ftbench summaries with horizontal and vertical bisections respectively:


executing tests:
  Load                          36.032 us/op,        229 ops
  Render                     59092.075 us/op,         48 ops



executing tests:
  Load                          37.687 us/op,        229 ops
  Render                    169454.931 us/op,        124 ops


105 glyphs are rejected outright because of their size. 76 glyphs fail with flawed horizontal bisections. We do not win that much indeed. It is possible to render such huge glyphs! It is natural that it takes a lot of time.

JPEG supports 0xFFFF x 0xFFFF according to wiki.
TIFF limits the size at 4Gb, which is kind of the same.

Perhaps we should impose those limits, but I will revert to vertical bisections perhaps too.

Alexei Podtelezhnikov <podtelez>
Group Member
Tue 05 Jun 2018 05:39:19 AM UTC, comment #9: 

Hmm.  Using the PFB test font attached to this issue, I don't see much difference in calling `ftview 100 <font>'.  It still takes a veeery long time to load.

Werner LEMBERG <wl>
Group administrator
Sun 03 Jun 2018 01:46:31 AM UTC, comment #8: 

I tried to mitigate this. Please test.

Alexei Podtelezhnikov <podtelez>
Group Member
Fri 01 Jun 2018 05:07:40 AM UTC, comment #7: 


> A large loop or an endless loop?


A large loop.  Too large values are already properly rejected.

> Why aren't checks in ftgrays.c:1890 sufficient?


This is the question.  It might make sense to restrict the bitmap width and height in addition to check that the x and y coordinates don't become too large.

> This is indeed the place to make the checks tighter is necessary.


We might also add some code to avoid an extreme design matrix.  The font in question has something like [1.0 0 1000000 1.0 0 0].

Werner LEMBERG <wl>
Group administrator
Thu 31 May 2018 08:54:27 PM UTC, comment #6: 

A large loop or an endless loop? Why aren't checks in ftgrays.c:1890 sufficient? This is indeed the place to make the checks tighter is necessary.

Alexei Podtelezhnikov <podtelez>
Group Member
Thu 31 May 2018 08:34:35 PM UTC, comment #5: 

Oh, similar ideas could be applied to the Type1 font matrix.

Werner LEMBERG <wl>
Group administrator
Thu 31 May 2018 08:33:12 PM UTC, comment #4: 

Don't use version 2.9, use 2.9.1!

After some thinking I tend to agree that FreeType should probably prohibit a 163851x5px bitmap – the width and height, as you suggest, could be restricted to, say, 0xFFFF pixels.  Another idea would be to disallow bitmaps where the ratio of width and height exceeds a factor, say, value 1000.

Other ideas and suggestions?

Werner LEMBERG <wl>
Group administrator
Thu 31 May 2018 09:43:05 AM UTC, comment #3: 

I'm not good at fonts. I just found there is something unnormal.
I'm using version 2.9 now.
I found that 2.7.1 checked this, but 2.9 removed the check,I think this check should also be added in subsequent versions,is that right?

lonely <flywrongsnow>
Thu 31 May 2018 09:08:17 AM UTC, comment #2: 

OK, I had a look, and I'm not sure whether this qualifies as a bug at all.  The subsetted font `Helvetica-Condensed-Light' (attached for convenience) contains an invalid font matrix entry which causes an extremely large horizontal shearing.  Consequently, FreeType rasters glyphs having dimensions like 163851x5px, which doesn't make much sense but is valid.  Note that such an array can easily be allocated, and rendering works fine also.  Many glyphs in this font, however, are already rejected because some point coordinates are too large (cf. lines 1890ff in file `src/smooth/ftgrays.c').

Isn't it the job of the client application to limit the glyph's bbox to some sensible values?  Alexei?

(file #44257)

Werner LEMBERG <wl>
Group administrator
Thu 31 May 2018 07:21:03 AM UTC, comment #1: 

Before I look into this: Please retry with current FreeType version (2.9.1.).

Werner LEMBERG <wl>
Group administrator
Thu 31 May 2018 06:36:20 AM UTC, original submission:  

when I add the code below after the function ft_glyphslot_preset_bitmap() in function ft_smooth_render_generic() according to version 2.7.1,the loop is stop.

the added code:
if ( slot->bitmap.width > 0x7FFF || slot->bitmap.rows > 0x7FFF )
{
FT_ERROR(( "ft_smooth_render_generic: glyph too large: %u x %u\n",
slot->bitmap->width, slot->bitmap->rows ));
error = FT_THROW( Raster_Overflow );
goto Exit;
}

lonely <flywrongsnow>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #44257:  Helvetica-Condensed-Light-buggy.pfb added by wl (24KiB - application/x-font-type1)
file #44252:  0015491_cp800datasheet.pdf added by flywrongsnow (399KiB - application/pdf)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by podtelez (Posted a comment)
  • -email is unavailable- added by wl
  • -email is unavailable- added by wl (Posted a comment)
  • -email is unavailable- added by flywrongsnow (Submitted the item)
  •  

    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 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-06-24 wl StatusConfirmed Fixed
        Open/ClosedOpen Closed
        Planned ReleaseNone 2.10.0
    2018-06-06 wl StatusReady For Test Confirmed
    2018-06-03 podtelez StatusNeed Info Ready For Test
    2018-05-31 wl Attached File- Added Helvetica-Condensed-Light-buggy.pfb, #44257
        Carbon-Copy- Added apodtele
    2018-05-31 wl StatusNone Need Info
        Assigned toNone wl
    2018-05-31 flywrongsnow Attached File- Added 0015491_cp800datasheet.pdf, #44252

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code