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

 
 

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

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

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( 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>
Project AdministratorIn charge of this item.
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>
Project 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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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>
Project 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>
Project AdministratorIn charge of this item.
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>
Project 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>
Project AdministratorIn charge of this item.
Tue 05 Jun 2018 07:12:12 PM UTC, comment #10:

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

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>
Project 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>
Project AdministratorIn charge of this item.
Sun 03 Jun 2018 01:46:31 AM UTC, comment #8:

I tried to mitigate this. Please test.

Alexei Podtelezhnikov <podtelez>
Project 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>
Project AdministratorIn charge of this item.
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>
Project 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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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.)

Attach Files:
   
   
Comment:
   

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)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    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
    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.3